Skip to content

fix: refresh runtime-proxy credentials before pruning a session on 404/401 - #123

Open
zoutei wants to merge 1 commit into
googlecolab:mainfrom
zoutei:fix/proxy-token-expiry
Open

fix: refresh runtime-proxy credentials before pruning a session on 404/401#123
zoutei wants to merge 1 commit into
googlecolab:mainfrom
zoutei:fix/proxy-token-expiry

Conversation

@zoutei

@zoutei zoutei commented Sep 5, 2026

Copy link
Copy Markdown
Contributor

Summary

The runtime-proxy token is short-lived, roughly 60 minutes (the server reports a 3600-second lifetime via tokenExpiresInSeconds), and expires well before an assignment is actually torn down. An expired token produces the exact same 404/401 that a genuinely terminated runtime would. exec, repl, console, and run treated any 404/401 as proof the session was lost and deleted the local binding outright, even though list_assignments() keeps listing the assignment and keeps minting it a fresh proxy token long after the previously-stored token stops working. A live, still-billing runtime could be destroyed by its own client roughly once per hour on any session kept open longer than that.

Fixes #106.

What changed

State.prune_or_recover_session() replaces the unconditional prune on this error path. Before deleting anything it asks the server. If the endpoint is still listed, it adopts the fresh token and url and keeps the local session; this invocation still fails, but the next one succeeds with the refreshed credential. If the endpoint is confirmed gone, it prunes as before. If the control plane is unreachable, it preserves the session rather than delete on an inconclusive check. This only runs reactively, in response to an actual 404/401 from the runtime proxy; there's no background or proactive token refresh.

Testing

Full test suite passes. Added unit coverage for all three outcomes of prune_or_recover_session, plus CLI-level tests covering both the pruned and preserved paths for exec.

…4/401

The runtime proxy token is short-lived and expires well before an
assignment is torn down, so an expired token produces the exact same
404/401 that a genuinely terminated runtime would. `exec`/`repl`/
`console`/`run` treated that error as proof the session was lost and
deleted the local binding outright -- even though `list_assignments()`
keeps listing the assignment (and keeps minting it a fresh proxy
token) long after the stored token has stopped working. A live,
billing runtime was being destroyed by its own client roughly once per
token lifetime on any long-running session.

`State.prune_or_recover_session()` asks the server before deleting:
if the endpoint is still listed, adopt the fresh token/url and keep
the session (this call still reports failure, but the next one
succeeds); if the endpoint is confirmed gone, prune as before; if the
control plane can't be reached at all, keep the session rather than
delete on an inconclusive check.

Fixes googlecolab#106.
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.

[Bug]: Live sessions are pruned locally after 60 minutes — proxy token expiry is misclassified as "session lost"

1 participant