fix(server): announce the boot auth state after the initial session restore - #571
fix(server): announce the boot auth state after the initial session restore#571johnthecat wants to merge 4 commits into
Conversation
…estore The session-store sync's boot tick now calls announce_current after reconciling, so a pairing host receives an opening AuthState (Disconnected included) without calling activateStoredSession.
| cleared_after_read_error = true; | ||
| } | ||
| } | ||
| pairing_host.auth_state.announce_current(); |
There was a problem hiding this comment.
This is right, but the reason it is right is invisible here. The call sits in the loop so it looks like every tick announces; what makes it boot only is that announce_current returns early once announced is set, and transition sets that flag on any real emission.
The old test asserted a tick finding nothing emits nothing, and its comment said a tick that finds nothing must not flash signed out at a signed-in host. That invariant still holds, but the assertion is gone and nothing replaces it. All three new tests cover boot. If someone later moves this line or drops the announced guard, the suite stays green and we get the polkadot-desktop bug back.
Can we add a test that signs in, ticks the notifier with nothing changed, and asserts no extra emission. A one line comment here pointing at the one shot guarantee would help too.
There was a problem hiding this comment.
Agreed, and the guard-dependent placement was the real problem. Restructured in f2471e5: the notifier no longer injects a boot tick, the task reconciles once at boot and announces there, and the change loop only reconciles. A change tick can no longer announce, so the one-shot behavior is in the control flow rather than in the announced flag. Added session_store_sync_stays_silent_on_an_unchanged_tick, which signs in through the store, fires a notification against the unchanged blob, and asserts no extra emission.
…store sync task The notifier no longer injects a synthetic initial tick. The sync task reconciles once at boot, announces the outcome, and then loops over real change notifications without announcing, so the one-shot opening state is visible in the control flow instead of depending on the announced guard. Adds a test that a change tick against an unchanged store stays silent.
The spawned task upgrades its weak reference when it first runs and bails if the runtime is already gone, so a pending boot reconcile never keeps a dropped runtime alive or emits to its platform.
2 participants
Problem
A pairing host boots with no answer on the
authcallback when there is nothing to restore. The core restores the persisted session on its own at boot, but a signed-out boot is a no-op transition and emits nothing, so a host cannot tell "still restoring" from "signed out". polkadot-desktop worked around it by guessingDisconnectedafter a timeout, which flashed onboarding at paired users and burned a pairing on every cold start (paritytech/polkadot-desktop#848).Solution
The boot tick of the session-store sync announces its outcome once it has reconciled,
Disconnectedincluded. Theauthcallback therefore always opens with the real boot state:Connectedfor a restored session,Disconnectedotherwise, with nothing emitted before it. ExplicitactivateStoredSessionkeeps its behaviour and never double-emits.Docs for
AuthPresenter, the nativeHostCallbacks, and the@parity/truapi-hostREADME describe the contract; the codegen golden is regenerated accordingly. Tests cover the signed-out boot, the restored boot, and the invalid-blob boot.