Skip to content

Keep the user signed in when the Pod is out of reach - #343

Merged
timgent merged 1 commit into
mainfrom
claude/issue-342-jgb4iz
Sep 2, 2026
Merged

Keep the user signed in when the Pod is out of reach#343
timgent merged 1 commit into
mainfrom
claude/issue-342-jgb4iz

Conversation

@timgent

@timgent timgent commented Sep 2, 2026

Copy link
Copy Markdown
Owner

A Solid session only becomes live once the provider answers a refresh, so a
cold start with no network cannot have one. isLoggedIn was the app's single
answer to "who is this?", and offline it said nobody: the nav offered to sign
them in, / opened the landing page, the sign-in nudges appeared — and,
because the PouchDB namespace is derived from the pod URL read over the
network, the app fell back to the empty local database and their lists were
not on screen at all. Nothing was lost, but there is no way to tell that from
the outside, which is why this reads as "it logged me out again".

SolidPodContext now has a third state. isReconnecting means a session is
stored on this device and nothing has told us it is over: the user is signed
in and merely unreachable, so the account stays in the nav behind an "Offline"
badge, a quiet banner says why the Pod is silent and that changes will sync
later, / still opens on the lists, and the sign-in prompts stay quiet.

rememberedSession.ts is what makes that possible across a reload: the WebID
and the resolved pod namespace are kept from the last live session, so the
right database opens with no network at all. Neither is a credential — the
refresh token stays in IndexedDB, owned by the auth library — and both are
forgotten the moment the session genuinely ends: a deliberate logout, the
provider rejecting the grant, or a start that finds no stored session.

Also claims the mid-session case: a live session going inactive without the
provider saying anything (the token lapsing while the radio is down) now books
its own retry, where before neither backoff covered it.

The account menu therefore no longer means "the pod is reachable", so the e2e
helper for a live session waits for the offline banner to be absent too, and
J's new list-writing test gets its own pod user rather than sharing testuser.

docs/offline.md has the whole story, including where offline-first goes next.

Closes #342

Co-Authored-By: Claude Opus 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_013WZr2RLkPKVWcRtMxzJc6x

A Solid session only becomes live once the provider answers a refresh, so a
cold start with no network cannot have one. `isLoggedIn` was the app's single
answer to "who is this?", and offline it said nobody: the nav offered to sign
them in, `/` opened the landing page, the sign-in nudges appeared — and,
because the PouchDB namespace is derived from the pod URL read over the
network, the app fell back to the empty `local` database and their lists were
not on screen at all. Nothing was lost, but there is no way to tell that from
the outside, which is why this reads as "it logged me out again".

`SolidPodContext` now has a third state. `isReconnecting` means a session is
stored on this device and nothing has told us it is over: the user is signed
in and merely unreachable, so the account stays in the nav behind an "Offline"
badge, a quiet banner says why the Pod is silent and that changes will sync
later, `/` still opens on the lists, and the sign-in prompts stay quiet.

`rememberedSession.ts` is what makes that possible across a reload: the WebID
and the resolved pod namespace are kept from the last live session, so the
right database opens with no network at all. Neither is a credential — the
refresh token stays in IndexedDB, owned by the auth library — and both are
forgotten the moment the session genuinely ends: a deliberate logout, the
provider rejecting the grant, or a start that finds no stored session.

Also claims the mid-session case: a live session going inactive without the
provider saying anything (the token lapsing while the radio is down) now books
its own retry, where before neither backoff covered it.

The account menu therefore no longer means "the pod is reachable", so the e2e
helper for a live session waits for the offline banner to be absent too, and
J's new list-writing test gets its own pod user rather than sharing testuser.

docs/offline.md has the whole story, including where offline-first goes next.

Closes #342

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013WZr2RLkPKVWcRtMxzJc6x
@vercel

vercel Bot commented Sep 2, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated
react-packing-app Ready Ready Preview Sep 2, 2026 8:05am UTC

@timgent
timgent merged commit 2d58238 into main Sep 2, 2026
4 checks passed
@timgent
timgent deleted the claude/issue-342-jgb4iz branch September 2, 2026 17:29
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.

When offline it looks like you're logged out

2 participants