- From the perspective of the relocatee:
- Nothing changes, but modifications to TA/OAuth will break during headless reciprocal actions (as the peer will use the old baseUrl)
- Even if we detect changes, what can we do to fix it on the peer?
- From the perspective of the peer:
- The List Applications page gets Conn Refused and renders "Peer Down or Relocated" link, or the admin actively clicks on "Configure"
- Brings up configure dialog with rpcUrl editable
- User types new URL and we retrieve manifest through the ApplicationType class:
- If new manifest reports a different app type, we barf (JiraApplicationTypeImpl.getManifest() attempts to download first)
- On conn refused we don't barf, but accept the new url
- If the new manifest has a different server id (will happen with non-UAL peers, or if the UAL peer is offline, or if the user mis-types the URL)
- Maybe simply change the server id in the db and emit an event. After all, a mere relocation would not change app type, auth config or entities
- ^--- fail, because might be UAL peer that is temporarily offline, so don't do anything and rely on server id detection in List Applications
- Conclusion: don't make state changes to keep the process reversible