Skip to content

fix(bd-3o8zmz46): evidence-based session expiry handling in hub-client - #268

Merged
shikokuchuo merged 3 commits into
mainfrom
bugfix/bd-3o8zmz46-ws-auth-expiry
Jun 10, 2026
Merged

fix(bd-3o8zmz46): evidence-based session expiry handling in hub-client#268
shikokuchuo merged 3 commits into
mainfrom
bugfix/bd-3o8zmz46-ws-auth-expiry

Conversation

@shikokuchuo

@shikokuchuo shikokuchuo commented Jun 10, 2026

Copy link
Copy Markdown
Member

When the Google ID token expired and One Tap renewal was unavailable, the hub 401'd every Automerge WS upgrade while the SPA stayed "logged in" showing a permanent "working offline" banner (bd-3o8zmz46).

  • /auth/me now reports the token's exp so the client schedules refresh from the real expiry (removing the refocus drift bug)
  • new useAuthProbe polls /auth/me while sync is disconnected and escalates on two consecutive 401s (renewal first, then an explicit "session expired" login screen)
  • network errors never clear auth, so genuine offline editing is unaffected

/auth/me now reports the token's exp and the client schedules refresh
from it (removing the refocus drift bug); a new useAuthProbe polls
/auth/me while sync is disconnected (two-strike 401 escalation);
network errors never log the user out; the login screen says when the
session expired.
@shikokuchuo
shikokuchuo force-pushed the bugfix/bd-3o8zmz46-ws-auth-expiry branch from ec38d81 to 5b14edd Compare June 10, 2026 13:08
@shikokuchuo
shikokuchuo merged commit 076971b into main Jun 10, 2026
4 of 5 checks passed
@shikokuchuo
shikokuchuo deleted the bugfix/bd-3o8zmz46-ws-auth-expiry branch June 10, 2026 13:28
AdaWorldAPI pushed a commit to AdaWorldAPI/q2 that referenced this pull request Aug 14, 2026
The comment above the sibling `git clone` layer asserted that "each build
re-clones fresh (no stale-cache problem the old pin was guarding against)".
That is true per q2 COMMIT and false per DEPLOY, and the difference is a
production outage.

Docker busts a layer when an INPUT changes. The sibling repos are not inputs —
nothing in this file can observe that lance-graph's HEAD moved — so a redeploy
of the same q2 commit reuses whatever clones the last build happened to take.

Measured today. Merging q2 #129 and OGAR quarto-dev#268 in the same minute started a
build whose lance-graph clone carried a codebook mirror one concept short of
OGAR's `class_ids::ALL`; `lance-graph-ogar`'s COUNT_FUSE panicked at
const-eval (E0080) and the deploy died at COMPILE, never reaching hydration.
lance-graph #953 fixed main eight minutes later — and the redeploy reproduced
the identical failure, because this layer served a lance-graph that no longer
had the bug anywhere but in Docker's cache.

Records the trap, the diagnostic ("a sibling that is demonstrably green on main
fails the build -> suspect this layer first"), and the two escapes: any q2
commit busts COPY and therefore this, or redeploy with the cache disabled.

Names the durable fix without making it: either explicit SHA ARGs bumped
deliberately (reproducible, staleness visible in the diff) or removing the
hand-maintained mirror entirely via hotplug enumeration. Both are architectural
calls; a comment is not one, and this commit does not pretend otherwise.

This commit also busts the COPY layer, so the next deploy clones fresh siblings
and should build against the already-green lance-graph main.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NMeiLmtDKhomJNSo2ecbJw
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