Skip to content

fix: Propagate player disconnect and server-switch failures - #15

Open
frederickbaier wants to merge 1 commit into
mainfrom
codex/handle-player-response-failures
Open

fix: Propagate player disconnect and server-switch failures#15
frederickbaier wants to merge 1 commit into
mainfrom
codex/handle-player-response-failures

Conversation

@frederickbaier

Copy link
Copy Markdown
Contributor

Disconnect and server-switch failures currently complete normally because PlayerIntegration discards controller replies and swallows exceptions. This hides the accurate disconnect failures introduced by controller PR 96 and prevents the Velocity and BungeeCord listeners’ existing error callbacks from running.

Parse PlayerDisconnectResponse and PlayerServerSwitchResponse, and complete the existing futures exceptionally on success=false, missing replies, malformed replies, transport failures, or interruption. Failures identify the operation and player, preserve their underlying cause, and restore the interrupt flag when interrupted. Successful replies, including already-offline disconnects, still complete normally. Login behavior is unchanged; no retries are added.

Validation:

  • All 68 API tests pass, including 14 new consumer regression cases. Ten failure-propagation cases failed against the previous implementation before the fix.
  • ./gradlew --configure-on-demand :api:check :platform:velocity:compileJava :platform:bungeecord:compileJava --console=plain passed.
  • Verified both proxy listeners already attach error callbacks to these futures. Tests exercise the real consumer methods with a fake NATS connection and protobuf replies; a live Minecraft proxy deployment was not run.

Compatibility: this is a behavioral breaking change for callers relying on failures being silently ignored: these futures now complete exceptionally. There are no public signature changes, protobuf/schema changes, dependency upgrades, or database migrations. The current protobuf dependency supports both reply types. This can be deployed with the old controller, but backend disconnect failures that the old controller incorrectly reports as success=true remain undetectable until controller PR 96 is deployed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant