Safer web session refresh, cleaner account resets, and explicit HIPAA guardrails

Fewer bad sign-outs during web session refresh

The most important change in 2026.10.3-deploy.cf5d82d8f649 is in the web app auth path.

We fixed a case where a late or stale refresh flow could clear a valid newly authenticated session. In practice, that meant a user could sign in successfully and still get signed out by an older request finishing afterward. The updated logic in app/src/lib/api.ts coordinates access token refresh so concurrent requests share one refresh flow, and it only expires the session when the refresh token still matches the one that request started with.

That detail matters. The code now guards against exactly this class of race with a comment that says: "A late request must never sign out a newly authenticated account." That is the behavior change in one line.

The same auth layer now returns a clearer expired-session path. If refresh fails and the session is actually gone, the app can surface a session-expired state instead of falling into a more ambiguous auth failure.

Account isolation now resets state more cleanly

This release also tightens what happens when auth state changes.

app/src/lib/auth.tsx now clears TanStack Query cache on login, logout, and related auth changes. It also listens for AUTH_CHANGED_EVENT from the API layer and re-syncs the current user from storage.

Why this shipped with the refresh fix is pretty simple: session reliability is only half the problem if one account's cached data can linger into the next session.

The current flow now does more of the cleanup work explicitly:

clear cached query data when a user logs in
clear stored session state on logout and session expiration
broadcast auth changes from the API layer
reload user state from storage when auth changes

That gives the web app better account isolation during login, logout, and expiration edges.

Release checks now exercise the auth refresh path

We also added release-time coverage for this path.

The GitHub Actions release workflow now runs:

Shell

node --experimental-strip-types --test app/tests/api.test.mts

before building the release artifacts.

That test file was added specifically to cover the web app API/session behavior. For this patch, that matters as much as the code change itself. Auth refresh bugs are often timing-sensitive, and they tend to slip through when the release pipeline only checks build output and deployment packaging.

Now the release workflow validates the auth/session path before shipping.

Receipt recovery without another deploy

This patch also adds an operations workflow for production publication reporting.

If hosting succeeded but the GitHub receipt failed, operators can now recover a verified production publication receipt by source SHA without rebuilding or redeploying the app. The runbook documents the command in deploy/aws/README.md:

Shell

python3 deploy/aws/manage.py report FULL_SOURCE_SHA

The documented behavior is specific:

it checks the public /api/ready source
it reuses an existing successful deployment
it does not rebuild, reupload, or restart the app
it does not retry ambiguous writes automatically

This is an internal operations change, but it closes a real gap in release reporting. If the app is already live and verified, recovering the publication receipt should not require another deployment just to repair the reporting record.

A HIPAA implementation plan now states the current limits plainly

The other notable addition is docs/HIPAA-IMPLEMENTATION-PLAN.md.

The important part is not just that the document exists. It states the current status directly: HIPAA enablement is planned, and it is not complete.

It also sets a clear usage limit for the current AWS EC2 plus Neon deployment: use synthetic patient data until the required agreements, technical controls, and operational review are complete.

That guidance is now linked from the AWS deployment runbook as well, so the restriction sits closer to the deployment workflow instead of living only in a separate planning document.

The document describes provider agreement steps, application gaps, owners, and release gates before using real patient data. It is planning guidance, not a compliance certification or legal opinion.

For a healthcare product, writing that down matters. A vague "later" is easy to ignore. A concrete implementation plan with explicit guardrails is harder to misread.

What changed in this patch

Here is the short version:

web session refresh is coordinated so concurrent requests share one refresh flow
stale refresh results are less likely to clear a valid newer session
auth changes clear cached query data and stored session state more consistently
release validation now includes the web app auth/session tests
production publication receipts can be recovered by source SHA without redeploying
HIPAA planning docs now explicitly say to use synthetic patient data for now

Most of this release is not flashy. It is the kind of patch that removes failure modes around state, timing, and operations. Those are usually the bugs that waste the most time once real teams start using the app every day.

If you want the latest build, you can get it from CodeSplash downloads.

Try the release and reply with feedback.