fix(guests): the middleware that keeps an active reader alive had never run

[mrviduus]

GuestActivityMiddleware exists so GuestCleanupWorker does not delete a guest who is still reading. It decided whether a request belonged to a guest by reading context.User.FindFirst("is_guest").

This API registers no ASP.NET authentication middleware at all — by design; every endpoint resolves identity by hand through GetUserId. So HttpContext.User is permanently empty, the check was always false, and the method returned on its first line for every request it ever served. LastActiveAt was written exactly once per guest, at creation.

The claim was never missing. AuthService has minted is_guest into every guest's access token since guest sessions shipped; ValidateAccessToken threw it away and returned only the id. It now has a sibling — ValidateAccessTokenIdentity — returning both, with the claim name as a single constant shared by the one place that mints it and the one that reads it.

What the damage actually was

Narrower than it looks, and the docs now say so rather than implying a data-loss emergency: GuestCleanupWorker's preservation filter also spares any guest holding a ReadingProgress row, so a guest who genuinely read a book survived regardless. The real exposure was a guest who opened books and never produced a progress row — plus a pipeline carrying a slice that did nothing, beneath a paragraph in Program.cs reasoning carefully about where to place it.

Two changes beyond the identity fix

• The debounce read the row it was trying to avoid writing. Every guest request did a SELECT on users to decide whether to skip the UPDATE. It is now an IMemoryCache entry, so the common path touches no database at all.
• The write is a targeted ExecuteUpdateAsync rather than loading an entity and saving it, so nothing else on the row can be written by accident.

Verification — the side effect, not the 200

That is the lesson this same middleware taught the first time, so it was checked the same way. Against a live local stack:

	last_active_at
one guest request	moves
five more inside the debounce window	does not move
an account's request	never touched (stays NULL)

The 200 is identical in all three cases — it was identical for the whole time the middleware did nothing.

The decision itself is now a pure function (ShouldWrite) with unit tests, including the inclusive boundary where the debounce and the cache expiry meet. The previous version had no testable seam, which is part of why the defect survived review.

• dotnet test tests/TextStack.UnitTests — 1240 pass (5 new)
• dotnet test tests/TextStack.IntegrationTests — 171 pass, 48 skipped
• dotnet format textstack.sln --verify-no-changes — clean

🤖 Generated with Claude Code

https://claude.ai/code/session_011rgEMvYYi4Egj99dVtvm6E