feat(be): record that a session is still in use

[sea-snake]

Design: #4224. Overview: #4230.

"This browser used this app 3 minutes ago" against "5 weeks ago" is what makes a session list worth reading, and what lets someone spot a session they do not recognise still being used rather than merely still existing.

Every refresh stamps, and three consumers make coarsening it unattractive: the session cap orders live sessions on this field, so inside a coarsening interval every session would look equally idle; the browser registry cap orders on the same signal, where an hour is long enough to drop a browser in use; and a user-facing list that can be an hour stale does not answer the question it exists to answer.

What the stamps cost, stated separately, because they are not the same write. last_refreshed_ns and the reference's last_used ride free: the list blob is rewritten either way, so they change bytes already in flight. The browser registry's last_used does not — stamp_browser_use is a read plus a write of the whole anchor, which serialises every passkey, OpenID credential, recovery key and verified email, pre-checks the email-recovery binding against its reverse index, and re-syncs five reverse indices by diffing vectors, all to move one u64. So this PR adds one anchor read-modify-write per five minutes of app use, per live session, where before there was one per sign-in. That is accepted here rather than argued away: the registry cap orders on this field, and a browser in use dropping out of the list is worse than the write. The coarsening argument above is about last_refreshed_ns and the user-facing list, and does not apply to the device field.

The same write carries three stamps:

Field	Lives on	Drives
last_used	the account reference	account eviction (#4235)
last_refreshed	the session record	the session cap (#4267) and the user-facing list
last_used	the device record	the registry cap (#4242) and the settings list

Stamping the device is the only reason refresh touches the anchor: it authenticates by session chain and never runs check_authorization. What that write buys is a use signal a sign-in stamp cannot give the browser list.

Stable writes scale with 1/T alongside the calls, so lowering the app-delegation TTL multiplies both.

Tests: session_refresh_stamp_tests (8), including a stamp for a session that is gone being refused rather than reporting success, and a refresh advancing the device's last_used while leaving its enrolment timestamp alone. PocketIC drives two refreshes a minute apart and reads the device back off identity_info.

[zeropath-ai]

✅ No security or compliance issues detected. Reviewed everything up to 5363e32.

Security Overview

• 🔎 Scanned files: 4 changed file(s)
• 🔗 Scan Link: https://zeropath.com/app/repositories/6d3e3b61-710b-4b2b-9c0b-43458b6314b6?scanId=88c3d2ea-6148-4fe1-9b27-01d77c4cd097&codeScanTypes=PrScan&tab=issues

Detected Code Changes

Change Type

Relevant files

Enhancement

► src/internet_identity/src/sessions.rs     Improve app_prepare_delegation by handling locator and adding pre-stamp storage recording ► src/internet_identity/src/storage.rs     Add record_session_use to track and stamp session usage and prune dead sessions ► src/internet_identity/src/storage/anchor.rs     Add stamp_browser_use to advance a browser's last_used timestamp ► src/internet_identity/src/storage/tests.rs     Extend tests with session_refresh_stamp_tests to validate new behavior

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

🔵 Needs a closer look

Two moderate test-coverage gaps remain unresolved.

Review details

Suppressed comments (2)

src/internet_identity/src/sessions.rs:383

• The new update-path side effect is only covered by direct Storage unit tests. The existing PocketIC session tests exercise app_prepare_delegation and browser listing separately, but no end-to-end test refreshes a session and then verifies the updated BrowserInfo.last_used through identity_info; this is the boundary where wiring the stamp or persisting the modified anchor could regress. Please add the described PocketIC regression test.

    storage_borrow_mut(|storage| storage.record_session_use(&locator, now)).map_err(
        |err| match err {
            StorageError::SessionNotFound { .. } => AppSessionError::NoSuchSession,
            other => AppSessionError::InternalCanisterError(other.to_string()),
        },
    )?;

src/internet_identity/src/storage/tests.rs:6585

• This test does not exercise the unregistered-browser case named here: storage_with_session() calls create_session, which registers a browser through resolve_browser, just like the registered-browser helper. As written, it is only another registered-browser refresh test and would not catch a regression in the intended no-registry-entry behavior. Remove the browser entry (or construct a session without one) before calling record_session_use.

    fn a_refresh_for_a_device_the_anchor_never_registered_still_stamps_the_session() {
        let (mut storage, anchor_number, key) = storage_with_session();

        storage.record_session_use(&key, 9_000).unwrap();

• Files reviewed: 4/4 changed files
• Comments generated: 0 new
• Review effort level: Lite

[sea-snake]

Both suppressed findings from the Copilot review, answered — they land differently.

sessions.rs:383 — the missing PocketIC coverage. It exists, one PR up. should_advance_the_device_last_used_on_every_refresh at #4245 asserts created_at == last_used at enrolment, advances 300 seconds, calls app_prepare_delegation, and reads the browser back through identity_info — exactly the boundary named, wiring included. This stack merges whole, so no change here.

storage/tests.rs:6585 — the test that doesn't test what it says. Correct, and the test is now deleted rather than repaired. storage_with_session() calls create_session, which registers a browser through resolve_browser, so the test was a duplicate of the registered-browser refresh above it under a name claiming the opposite.

Constructing the orphan, as suggested, would pin a state that cannot occur. A browser is given up only at MAX_BROWSERS inside resolve_browser; the write gate sweeps that browser's sessions in the same write; and sync_session_index removes their principal-index entries along with them. So when the browser goes the session goes, and a later mint stops at NoSuchSession in find_caller_session before record_session_use is reached at all.

That also settles stamp_browser_use's browser-not-found branch, which we looked at while here: it stays a no-op. It is unreachable for the reason above, and nothing observable would go wrong if it were reached — browsers_info() builds the devices list from registry entries, so a missing entry means no row rather than a stale one. The same if also covers the ordinary case of a repeat stamp inside one message, which must no-op.

🤖 Generated with Claude Code

https://claude.ai/code/session_01LVi99RYo2jyi2kCurgovNJ