Repository navigation
fix: Hear a network's deletion at once where no binding declares it - #846
Merged
Merged
Conversation
Base automatically changed from
fix/presence-reconciles-every-presence-on-start
to
main
November 3, 2026 10:01
A presence that no hub binding declares hears its network's deletion only at its next resync. With the resync at an hour, this test fails on the restart fix's branch: the network waits for its context.
The replicator mirrors every Network onto the hub and deletes the mirror as soon as the Network is deleted. The presence controller now watches those mirrors and maps a mirror's deletion, or the first update of a deletion a finalizer holds, to the hub copies of the network's contexts in the mirror's namespace, as it maps an interface copy to its presence. The resync stays, for an event that never arrives. Closes #829
vvoytovych
force-pushed
the
fix/presence-hears-network-deletion-at-once
branch
from
November 3, 2026 10:09
e06e37a to
89643f8
Compare
vvoytovych
marked this pull request as ready for review
November 3, 2026 13:01
scotwells
approved these changes
Nov 3, 2026
andrewb3000
approved these changes
Nov 3, 2026
4 tasks done
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A presence that no hub binding declares heard its Network's deletion only at its next resync, up to a minute later (the wait): staging's kept-interface test measured 65 s (#829). The replicator mirrors every Network onto the hub (the mirror) and deletes the mirror as soon as the Network is deleted (its delete). The presence controller now watches those mirrors and maps a mirror's deletion to the hub copies of the network's contexts in the same namespace, as it maps an interface copy to its presence; the resync stays for an event that never arrives.
Built on #844, the restart fix, now on
main: the map reads the hub's context copies from the informer #844 added.Changes
networkpresence_controller.goCorner cases
TestANetworkDeletionReachesAPresenceNothingDeclaresAtOnceTestANetworkMirrorMapsToItsPresencesInItsNamespaceTestOnlyANetworkMirrorGoingBringsItsPresencesBackTestNetworkPresenceMarksOnlyTheContextOfTheNetworkBeingDeletedand the reconcile's own readCost
Test plan
golangci-lintv2.15.0 passes.kept_test.py's undeclared network went 4 s after its delete, where it took 65 s on fix: Name a cell's network contexts from the location it serves #833's build.Closes #829