Context
PR #223 fixes #222 — on Harper v5 session.oauth is a read-only tracked object, so the periodic-validation path's in-place lastValidated update threw Cannot assign to read only property 'lastValidated'. The runtime fix (rebuild session.oauth, then persist via session.update()) is correct and shipping in 2.5.1.
The gap (test hardening — not a runtime defect)
The regression test in test/lib/sessionValidator.test.js proves only the in-memory replacement, not persistence. createMockSession.update(data === this) no-ops, and every assertion reads the already-reassigned in-memory session.oauth. Consequence: removing await session.update(session) from the production path would leave this test (and the existing periodic-validation test) green, while a real deployment's next request would reload the stale timestamp and reproduce the original every-request-validation symptom. The guard doesn't actually protect the fix.
Ask
Make the regression test mutation-resistant:
- Have the fake session store snapshot what
update() persists instead of no-op'ing.
- Assert exactly one
update() call carrying the rebuilt metadata (including the advanced lastValidated).
- Reload a second request from that persisted snapshot and assert it is throttled (validation skipped) with all OAuth metadata intact.
Non-blocking; scheduled after the 2.5.1 patch ships. Refs #222, #223.
Context
PR #223 fixes #222 — on Harper v5
session.oauthis a read-only tracked object, so the periodic-validation path's in-placelastValidatedupdate threwCannot assign to read only property 'lastValidated'. The runtime fix (rebuildsession.oauth, then persist viasession.update()) is correct and shipping in 2.5.1.The gap (test hardening — not a runtime defect)
The regression test in
test/lib/sessionValidator.test.jsproves only the in-memory replacement, not persistence.createMockSession.update(data === this)no-ops, and every assertion reads the already-reassigned in-memorysession.oauth. Consequence: removingawait session.update(session)from the production path would leave this test (and the existing periodic-validation test) green, while a real deployment's next request would reload the stale timestamp and reproduce the original every-request-validation symptom. The guard doesn't actually protect the fix.Ask
Make the regression test mutation-resistant:
update()persists instead of no-op'ing.update()call carrying the rebuilt metadata (including the advancedlastValidated).Non-blocking; scheduled after the 2.5.1 patch ships. Refs #222, #223.