Add dedicated voting proxy routing - #1551
Conversation
AI disclosure: This commit message was written with assistance from ChatGPT.
|
@codex review Please review the dedicated voting-proxy routing introduced in this PR, especially that it uses only confirmed backend presence, never fans out through Java 21 Maven CI passes. AI disclosure: This review request was written with assistance from ChatGPT. |
AI disclosure: This commit message was written with assistance from ChatGPT.
|
Updated in AI disclosure: This comment was written with assistance from ChatGPT. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b6b01f8964
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // A dedicated voting proxy has no player-facing proxy state. Its confirmed | ||
| // backend presence selects one destination, so never fan a vote out merely | ||
| // because a legacy configuration still has SendVotesToAllServers enabled. | ||
| if (getConfig().getSendVotesToAllServers() && !isDedicatedVotingProxyEnabled()) { |
There was a problem hiding this comment.
When a dedicated proxy starts or recovers while a player is already online, this branch caches any vote received before the presence snapshot arrives. Completing an ordinary snapshot populates backendPlayerPresenceTracker, but the snapshot handler only completes pending cross-backend handoffs and never invokes login or checkOnlineVotes for the newly confirmed players; the periodic retry paths only retry broadcasts. Consequently, these rewards remain cached until the player generates a new login, potentially for the rest of their session. Process voter-keyed cached votes when a completed snapshot confirms their presence.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in e72772c5. Once a complete presence snapshot is accepted, dedicated mode now runs the existing login/cache-draining path for every confirmed player on that backend. This releases votes cached while the dedicated proxy was waiting for startup/recovery presence.
The existing token-bound handoff completion runs first; its players are excluded from the snapshot drain so they cannot receive a duplicate login callback.
Added dedicatedSnapshotDrainsCachedVotesForConfirmedPlayers coverage.
AI disclosure: This reply was written with assistance from ChatGPT.
AI disclosure: This commit message was written with assistance from ChatGPT.
|
@codex review Please review latest head ( Java 21 Maven CI passes. AI disclosure: This review request was written with assistance from ChatGPT. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e72772c5af
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| }); | ||
| } | ||
| for (PendingPresenceHandoff handoff : completed) { | ||
| completedPlayers.add(handoff.playerUuid); |
There was a problem hiding this comment.
When a player reconnects on the destination backend before the snapshot is captured and the new login event is lost, the snapshot can install the player's new connection token while the pending handoff still contains the old token. This UUID is added to completedPlayers unconditionally, but the token-bound branch skips login because the tokens differ, and processDedicatedSnapshotLogins then excludes the UUID as if the callback had run. The complete recovery snapshot therefore fails to drain that confirmed player's voter-keyed rewards until another login; only add the UUID to the exclusion set when the token comparison succeeds and login is invoked.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in a8a7b806. A handoff UUID is now added to the snapshot-drain exclusion set only after the snapshot still matches that handoff's connection token and the handoff path invokes login. If the snapshot contains a newer connection, it is no longer excluded and the normal completed-snapshot drain processes its cached rewards.
AI disclosure: This reply was written with assistance from ChatGPT.
AI disclosure: This commit message was written with assistance from ChatGPT.
1 participant
Summary
DedicatedVotingProxyproxy setting for one central voting proxy when regional proxies do not run VotingPluginSendVotesToAllServersbehavior in dedicated mode: when enabled, votes still reach every backend; when disabled, a confirmed online player routes to their backend and unknown/offline players use the existing cache pathPLUGINMESSAGING; it falls back to normal proxy routing and logs the misconfigurationConfiguration
On the dedicated voting proxy only:
Regional proxies should not run VotingPlugin. Backends use the same non-
PLUGINMESSAGINGglobal-message transport and their configuredServername.Validation
git diff --check: passedAI disclosure: This content was written with assistance from ChatGPT.