Galaxy: a SubscribeAsync still awaiting the old session's reply can register old-session handles after a reconnect #861
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Found while fixing #859 (pre-existing, not introduced by it).
_runtimeGenerationchanges only on teardown, not on reconnect. ASubscribeAsync(or subscribe-once read) whoseSubscribeBulkwas issued on the old gateway session and returns afterReopenAsync+ResubscribeAllAsynccan stillRegisterthe old session's item handles in the registry. The new session may reuse those handle numbers for other tags (MXAccess handles are small integers), so events could fan to the wrong subscription, or the subscription stays bound to a dead handle. #859's per-pump epoch stops held events crossing sessions but not this registration. Fix idea: carry a session epoch into the subscribe call and refuse/redo registration when it changed while awaiting the reply; add a test with a reply that completes after a reconnect.Fixed with #859 (
d08e9002,133bc07d,a8d3790b). Pushed to master ine857135e. The registry is per-session:StartNewSession()runs before and after the gateway session swap inReopenAsync(and inReplayAsyncwhen no reopen did); registration with a stale session is refused atomically; a straddlingSubscribeAsyncis re-issued (≤3), a straddling read returnsBadCommunicationError; old-session handle numbers are never sent to UnsubscribeBulk; the replay re-subscribes only older-session entries and the probe watcher re-subscribes only its stale platforms.