@@ -0,0 +1,10 @@
+---
+'@objectstack/plugin-auth': patch
+---
+
+Clause-②: no
+Metadata-protocol: none
+
+The session activity heartbeat now runs on every deployment. `sys_session.last_activity_at` is "the last request on this session", and Setup → Sessions shows it so an administrator can tell two of one user's sessions apart. Until now it was written only while `sessionIdleTimeoutMinutes` was above 0, so on a default deployment (no idle or absolute limit) the Last Activity column stayed empty.
+
+It is still written at most once a minute per session. When neither the idle nor the absolute limit is configured, the `sys_session` read that feeds it is throttled too: a per-process memo, per session and bounded in size, skips the read for 60 seconds after one. With a limit configured, every request still reads the session row, as enforcement needs.
@@ -450,22 +450,90 @@ export async function unlockUser(this: Pick<PasswordSessionPolicyHost, 'getDataE
   return true;
 }
 
+/**
+ * [#25343] The `last_activity_at` heartbeat's throttle: at most one write per
+ * session per minute, and — when no session limit is configured — at most one
+ * `sys_session` read per session per minute as well.
+ */
+const SESSION_HEARTBEAT_INTERVAL_MS = 60_000;
+/**
+ * [#25343] The most sessions one {@link SessionHeartbeatMemo} remembers. An
+ * entry is worth keeping for one {@link SESSION_HEARTBEAT_INTERVAL_MS} only,
+ * so the cap is a bound on memory, not on correctness: an evicted session is
+ * read once more, exactly as if the memo had expired.
+ */
+export const SESSION_HEARTBEAT_MEMO_MAX = 10_000;
+
+/**
+ * [#25343] Per-process, per-session memo of "this session's row was read less
+ * than a minute ago", consulted only when neither the idle nor the absolute
+ * limit is configured (ADR-0069 D4). There the read exists only to feed the
+ * heartbeat, which writes at most once a minute, so a read inside that minute
+ * cannot lead to a write and is skipped. With a limit on, every request still
+ * reads: enforcement needs the row's current state, and the memo is not asked.
+ *
+ * Bounded least-recently-noted: a `Map` keeps insertion order, `note` moves
+ * the session to the end, and the oldest entry — the stalest — is dropped
+ * past {@link SESSION_HEARTBEAT_MEMO_MAX}.
+ */
+class SessionHeartbeatMemo {
+  private readonly readAt = new Map<string, number>();
+
+  isFresh(sessionId: string, now: number): boolean {
+    const at = this.readAt.get(sessionId);
+    return at !== undefined && now - at <= SESSION_HEARTBEAT_INTERVAL_MS;
+  }
+
+  note(sessionId: string, now: number): void {
+    this.readAt.delete(sessionId);
+    this.readAt.set(sessionId, now);
+    if (this.readAt.size > SESSION_HEARTBEAT_MEMO_MAX) {
+      const oldest = this.readAt.keys().next().value;
+      if (oldest !== undefined) this.readAt.delete(oldest);
+    }
+  }
+}
+
+/**
+ * [#25343] One memo per data engine, held weakly: in a running process that
+ * is the one engine the manager is wired to (so the memo is per-process), and
+ * a second engine — another manager, a test double — never answers from the
+ * first one's memo.
+ */
+const sessionHeartbeatMemos = new WeakMap<object, SessionHeartbeatMemo>();
+
+function sessionHeartbeatMemoFor(engine: object): SessionHeartbeatMemo {
+  let memo = sessionHeartbeatMemos.get(engine);
+  if (!memo) {
+    memo = new SessionHeartbeatMemo();
+    sessionHeartbeatMemos.set(engine, memo);
+  }
+  return memo;
+}
+
 /** The body of `AuthManager#enforceSessionControls`; the method's docblock there is its contract. */
 export async function enforceSessionControls(this: Pick<PasswordSessionPolicyHost, 'config' | 'getDataEngine' | 'logDurabilityDegradation'>, sessionId: string | undefined, createdAtHint: unknown): Promise<void> {
   const idleMin = Math.floor(Number(this.config.sessionIdleTimeoutMinutes) || 0);
   const absHrs = Math.floor(Number(this.config.sessionAbsoluteMaxHours) || 0);
-  if (idleMin <= 0 && absHrs <= 0) return;
+  // [#25343] Both limits off no longer returns here: `last_activity_at` is
+  // "the last request on this session" on every deployment, not only where an
+  // idle timeout reads it (ruling 6358844136, letter A). What both-off buys
+  // instead is the memo below, so the added read is throttled like the write.
+  const limitsOff = idleMin <= 0 && absHrs <= 0;
   const engine = this.getDataEngine();
   if (!engine || !sessionId) return;
+  const memo = limitsOff ? sessionHeartbeatMemoFor(engine) : undefined;
+  if (memo?.isFresh(sessionId, Date.now())) return;
   try {
     const SYSTEM_CTX = { isSystem: true, positions: [], permissions: [] };
     const srow = await engine.findOne('sys_session', {
       where: { id: sessionId },
       fields: ['id', 'created_at', 'last_activity_at', 'revoked_at'],
       context: SYSTEM_CTX,
     });
-    if (!srow?.id || srow.revoked_at) return;
     const now = Date.now();
+    memo?.note(sessionId, now);
+    if (!srow?.id || srow.revoked_at) return;
     let reason: string | undefined;
     if (absHrs > 0) {
       const created = srow.created_at ?? createdAtHint;
@@ -498,33 +566,42 @@ export async function enforceSessionControls(this: Pick<PasswordSessionPolicyHos
       ));
       return;
     }
-    if (idleMin > 0) {
-      const la = srow.last_activity_at ? new Date(srow.last_activity_at as any).getTime() : 0;
-      if (now - la > 60_000) {
-        await engine.update('sys_session', { id: sessionId, last_activity_at: new Date(now) }, { context: SYSTEM_CTX } as any)
-          .catch((e: unknown) => this.logDurabilityDegradation(
-            'AuthManager: the session activity heartbeat was NOT written — the request '
-              + 'succeeds and the session stays live, so nothing looks wrong. '
-              + '`last_activity_at` keeps its older value, so the idle-timeout clock (ADR-0069 '
-              + 'D4) keeps measuring from that older instant and this session will be revoked '
-              + 'as idle EARLIER than the configured window — an active user signed out '
-              + 'mid-session for no visible reason. Remedy: make the sys_session update land; '
-              + 'the heartbeat retries on the next request past the one-minute throttle.',
-            e,
-            { object: 'sys_session', sessionId, field: 'last_activity_at' },
-          ));
-      }
+    // [#25343] The heartbeat runs on every deployment, idle timeout or not.
+    const la = srow.last_activity_at ? new Date(srow.last_activity_at as any).getTime() : 0;
+    if (now - la > SESSION_HEARTBEAT_INTERVAL_MS) {
+      await engine.update('sys_session', { id: sessionId, last_activity_at: new Date(now) }, { context: SYSTEM_CTX } as any)
+        .catch((e: unknown) => this.logDurabilityDegradation(
+          'AuthManager: the session activity heartbeat was NOT written — the request '
+            + 'succeeds and the session stays live, so nothing looks wrong. '
+            + '`last_activity_at` keeps its older value, so the idle-timeout clock (ADR-0069 '
+            + 'D4) keeps measuring from that older instant and this session will be revoked '
+            + 'as idle EARLIER than the configured window — an active user signed out '
+            + 'mid-session for no visible reason. Remedy: make the sys_session update land; '
+            + 'the heartbeat retries on the next request past the one-minute throttle.',
+          e,
+          { object: 'sys_session', sessionId, field: 'last_activity_at' },
+        ));
     }
   } catch (e) {
     // Never break a request. [#12981] But a control that silently stops
     // running is a control the operator still believes is on.
     this.logDurabilityDegradation(
-      'AuthManager: the per-request session controls did not run to completion — the request '
-        + 'succeeds, so nothing looks wrong. Idle and absolute session limits (ADR-0069 D4) '
-        + 'were not evaluated for this session, so a session past its limit is neither revoked '
-        + 'nor reported by the branch above. Remedy: this is the LOOKUP half failing (the '
-        + 'sys_session read), so check driver connectivity and read permission on sys_session; '
-        + 'the controls re-run on the next request.',
+      limitsOff
+        // [#25343] With no limit configured the read feeds only the heartbeat,
+        // so that is what was lost — saying "limits not evaluated" would name
+        // a control this deployment never turned on.
+        ? 'AuthManager: the session activity heartbeat did not run — the request succeeds, so '
+          + 'nothing looks wrong. `last_activity_at` was not advanced for this session, so the '
+          + 'Sessions list shows an older Last Activity than the session really has. Remedy: '
+          + 'this is the LOOKUP half failing (the sys_session read), so check driver '
+          + 'connectivity and read permission on sys_session; the heartbeat re-runs on the '
+          + 'next request.'
+        : 'AuthManager: the per-request session controls did not run to completion — the request '
+          + 'succeeds, so nothing looks wrong. Idle and absolute session limits (ADR-0069 D4) '
+          + 'were not evaluated for this session, so a session past its limit is neither revoked '
+          + 'nor reported by the branch above. Remedy: this is the LOOKUP half failing (the '
+          + 'sys_session read), so check driver connectivity and read permission on sys_session; '
+          + 'the controls re-run on the next request.',
       e,
       { object: 'sys_session', sessionId, idleMinutes: idleMin, absoluteHours: absHrs },
     );
 
@@ -4806,11 +4806,18 @@ describe('AuthManager', () => {
       find: vi.fn(async () => []),
     });
 
-    it('is a no-op when idle + absolute are both off', async () => {
+    // [#25343] Both off no longer means no-op: the `last_activity_at`
+    // heartbeat runs on every deployment (ruling 6358844136, letter A); its
+    // memo and throttle are pinned in session-heartbeat-default-config.test.ts.
+    it('with idle + absolute both off it revokes nothing but still writes the heartbeat', async () => {
       const engine = oneEngine({ id: 's1', created_at: new Date(0).toISOString() });
       const m = mgr(engine, {});
       await (m as any).enforceSessionControls('s1', undefined);
-      expect(engine.findOne).not.toHaveBeenCalled();
+      expect(engine.findOne).toHaveBeenCalledTimes(1);
+      expect(engine.update).toHaveBeenCalledTimes(1);
+      const [, patch] = engine.update.mock.calls[0] as unknown as [string, Record<string, unknown>];
+      expect(patch.last_activity_at instanceof Date).toBe(true);
+      expect(patch.revoke_reason).toBeUndefined();
     });
 
     it('revokes (absolute_max) when the session is older than the absolute cap', async () => {
 
@@ -8882,10 +8882,12 @@ export class AuthManager {
 
   /**
    * ADR-0069 D4 — idle / absolute session enforcement, run per request from
-   * `customSession`. No-op when both are off. Revokes (expires in place +
-   * stamps revoked_at/revoke_reason) when a limit is exceeded so better-auth
-   * returns no session on the NEXT request; otherwise touches `last_activity_at`
-   * (throttled to once a minute). Best-effort — never throws.
+   * `customSession`. Revokes (expires in place + stamps
+   * revoked_at/revoke_reason) when a limit is exceeded so better-auth returns
+   * no session on the NEXT request; otherwise touches `last_activity_at`
+   * (throttled to once a minute). [#25343] The touch runs on every deployment,
+   * limits or not; with both off, a per-process 60-second memo per session
+   * skips the `sys_session` read too. Best-effort — never throws.
    */
   private enforceSessionControls(sessionId: string | undefined, createdAtHint: unknown): Promise<void> {
     // [#25224 cut 3] The body moved to `auth-manager-password-session-policy.ts` (see `PasswordSessionPolicyHost`).
 
@@ -217,16 +217,23 @@ const arrange = async (config: Record<string, unknown> = {}) => {
  * reads twice). Every later request is the case the count is about.
  *
  * [#24061] An in-process session read signs no JWT any more, so it no longer
- * mints the signing key either: the warm-up request writes nothing. A write
- * inside the request is still declined across — pinned below with the
- * idle-timeout heartbeat, the write a session read still makes.
+ * mints the signing key either. [#25343] The one write a session read still
+ * makes is the `last_activity_at` heartbeat, which now runs on every
+ * deployment — on a session's first request and then at most once a minute.
+ * So the warm-up is one request per session: each writes exactly that
+ * heartbeat, and every request after it inside the minute writes nothing,
+ * which is the steady state of a live session. A write inside the request is
+ * still declined across — pinned below with that same heartbeat.
  */
 const arrangeWarm = async () => {
   const a = await arrange();
   const observersBefore = a.probe.middlewareCount();
   const warm = await resolveRequest(a, a.bearers.owner);
-  expect(warm.writes).toEqual([]);
+  expect(warm.writes).toEqual(['update sys_session']);
   expect(a.probe.middlewareCount()).toBe(observersBefore + 1);
+  for (const bearer of [a.bearers.member, a.bearers.leaver, a.bearers.operator]) {
+    expect((await resolveRequest(a, bearer)).writes).toEqual(['update sys_session']);
+  }
   return a;
 };
 
@@ -375,11 +382,16 @@ describe.concurrent('the real customSession hook and resolveAuthzContext resolve
     expect(countOf(reads, 'sys_user_position')).toBe(1);
   });
 
-  it('a write inside the request (the idle-timeout heartbeat): the memo declines, the envelope is unchanged', async () => {
-    // [ADR-0069 D4] With an idle timeout configured, the hook stamps the
-    // session's `last_activity_at` AFTER it resolved the grants — at most once
-    // a minute, and on a session's first request since sign-in.
-    const a = await arrange({ sessionIdleTimeoutMinutes: 30 });
+  it.each([
+    ['the default config (no session limit)', {}],
+    ['an idle timeout', { sessionIdleTimeoutMinutes: 30 }],
+  ])('a write inside the request (the heartbeat, under %s): the memo declines, the envelope is unchanged', async (_label, config) => {
+    // [ADR-0069 D4] The hook stamps the session's `last_activity_at` AFTER it
+    // resolved the grants — at most once a minute, and on a session's first
+    // request since sign-in. [#25343] On every deployment, not only where an
+    // idle timeout is configured: that once-a-minute request is the one that
+    // pays the second resolution.
+    const a = await arrange(config);
     // Register core's write observer with an anonymous request first (no
     // session, nothing written), so the ONLY reason left for the member's
     // first request to read twice is the write inside it.