perf(mobile): pause elapsed-time timers on hidden thread screens

[juliusmarminge]

Problem

Mobile keeps thread routes mounted after you navigate away. The working-duration label (WorkingTimer) and the live subagent status (ProviderSubagentBar) each ran an ungated 1 s setInterval. It kept firing while the screen was unfocused, while the app was backgrounded or inactive, and re-rendered the hidden screen 60 times a minute.

Fix

A new hook, useVisibleSecondClock(enabled), ticks once a second only while enabled && focused && AppState === "active". When ticking resumes it re-reads Date.now() in a layout effect, so the label shows the true elapsed time on the first frame after you return. Both labels use the hook. Nothing else changes: the visible tick rate and interval phase stay the same.

The hook also re-reads AppState.currentState after its listener is attached. This closes a small race where a change between the first render and the passive subscription would otherwise be missed. A focused regression test covers it, and that test fails without the re-read.

jsdom is now declared as an apps/mobile devDependency, matching apps/web's ^30.0.1. The new test file uses it. Before this, it resolved only through the workspace's Vite+ peer. The lockfile change is three lines on the mobile importer and pulls in no new packages.

Before / after

Measured with an instrumented Vitest test that uses fake timers in jsdom. Navigation focus and AppState are mocked, and each scenario runs for 60 simulated seconds. "Before" is the parent commit's timer code, copied verbatim.

Timer	Scenario	Before	After
WorkingTimer, ProviderSubagentBar (live)	visible (focused, active)	60 commits/min	60 commits/min
both	unfocused retained route	60 commits/min	0
both	focused, app background	60 commits/min	0
both	focused, app inactive	60 commits/min	0
WorkingTimer	600 s background → active	600 commits while hidden	0, label shows +600 s on first active render

Evidence (sanitized):

• README: method and limits
• battery-measure.test.tsx: measurement harness
• measurement.txt: raw results
• test-run.txt: hook tests plus measurement run, 27/27 pass

Screenshots don't apply: the visible label looks the same before and after. The change is in how often it ticks while hidden.

Limits

• These numbers count fake-clock JS interval callbacks and React commits. They are not OS wakeups, CPU time, or battery measurements.
• No device or simulator proof yet, which is why this PR is a draft. Still needed: a profile on a real iOS/Android device (for example Instruments Energy Log or Android Battery Historian/Perfetto) showing JS-thread wakeups while a working thread sits backgrounded or on an unfocused retained route, before vs after.
• This covers only these two labels. It is not a full mobile battery audit.

Verification

• vp test run apps/mobile/src/features/threads/use-visible-second-clock.test.tsx: 9/9 pass, including the new AppState race test, which fails without the fix.
• Measurement harness: 18/18 scenarios pass.
• apps/mobile typecheck passes. Targeted lint shows 0 errors (the warnings are already on base, in untouched code). Format passes.

Stack: #15096 → #15248 → #15385 → this PR.

Implemented with Claude Opus 5.5 (1M context) in Claude Code via T3 Code.

🤖 Generated with Claude Code

---

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

ℹ️ No successful main baseline artifact is available yet. This run establishes the initial measurement.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	—	5.0 KiB	—	6.8 KiB	✅
Codex	Thread snapshot wire	—	3.8 KiB	—	4.9 KiB	✅
Codex	Live turn WebSocket wire	—	1.2 KiB	—	2.0 KiB	✅
Codex	Live turn WebSocket decoded	—	20.9 KiB	—	29.3 KiB	✅
Codex	Live turn messages	—	2	—	8	✅
Claude	Total thread wire	—	5.0 KiB	—	6.8 KiB	✅
Claude	Thread snapshot wire	—	3.8 KiB	—	4.9 KiB	✅
Claude	Live turn WebSocket wire	—	1.2 KiB	—	2.0 KiB	✅
Claude	Live turn WebSocket decoded	—	21.2 KiB	—	29.3 KiB	✅
Claude	Live turn messages	—	2	—	8	✅

Baseline: unavailable · PR result: bca4197 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 108.5 KiB
• Claude decoded thread snapshot: 108.8 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — The PR introduces a bounded production hook that pauses hidden-screen timer updates and adds focused tests, but it also adds two line-level oxlint suppression directives for the new state updates. Those static-analysis overrides require human review.

No code changes detected at bca4197. Prior analysis still applies.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

Important

Review skipped

We couldn't safely recover the incremental review. No full review was started, and the last reviewed checkpoint was preserved. Retry later, or explicitly request a full review by commenting @coderabbitai full review.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Repository: pingdotgg/t3code/.coderabbit.yaml
• Review profile: CHILL
• Plan: Team
• Run ID: 2b1edf7d-a492-491b-9c09-8d51e0e4e90d

📥 Commits

Reviewing files that changed from the base of the PR and between 918cf5f and 4b291fc.

⛔ Files ignored due to path filters (1)

• pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml

📒 Files selected for processing (5)

• apps/mobile/package.json
• apps/mobile/src/features/threads/ProviderSubagentBar.tsx
• apps/mobile/src/features/threads/floating-working-control.tsx
• apps/mobile/src/features/threads/use-visible-second-clock.test.tsx
• apps/mobile/src/features/threads/use-visible-second-clock.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 3 remain after this review.

---

📝 Walkthrough

Walkthrough

The mobile app adds useVisibleSecondClock, which updates its timestamp only while enabled, focused, and active. Two thread components use the hook, and tests cover its ticking, pause, resume, and cleanup behavior.

Changes

Visible second clock

Layer / File(s)	Summary
Clock lifecycle and validation apps/mobile/src/features/threads/use-visible-second-clock.ts, apps/mobile/src/features/threads/use-visible-second-clock.test.tsx, apps/mobile/package.json	Adds a clock hook that tracks focus and app activity, starts a one-second interval when enabled, focused, and active, and refreshes the timestamp when ticking resumes. Tests cover ticking, pauses, resumes, and cleanup. Adds jsdom as a development dependency.
Thread component adoption apps/mobile/src/features/threads/ProviderSubagentBar.tsx, apps/mobile/src/features/threads/floating-working-control.tsx	Both components use useVisibleSecondClock instead of maintaining local timestamp intervals.

Priority: ⬇️ Low

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Sequence Diagram(s)

sequenceDiagram
  participant ProviderSubagentBar
  participant WorkingTimer
  participant useVisibleSecondClock
  participant NavigationFocus
  participant ReactNativeAppState
  participant Interval
  ProviderSubagentBar->>useVisibleSecondClock: Request timestamp with live state
  WorkingTimer->>useVisibleSecondClock: Request timestamp enabled
  useVisibleSecondClock->>NavigationFocus: Track screen focus
  useVisibleSecondClock->>ReactNativeAppState: Track app activity
  useVisibleSecondClock->>Interval: Run ticks when enabled, focused, and active
  Interval->>useVisibleSecondClock: Update timestamp once per second
  useVisibleSecondClock->>ProviderSubagentBar: Provide timestamp
  useVisibleSecondClock->>WorkingTimer: Provide timestamp

Loading

Merge Risk: ⚪ Minimal · up to 4b291

The timer change is mergeable after normal checks; no actionable issue remains.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 44.44% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 9 functions across 4 files. (1 skipped: 1…	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly identifies the mobile performance change: pausing elapsed-time timers on hidden thread screens.
Description check	✅ Passed	The description explains the problem, implementation, measured results, verification, and limitations. It does not include the required Scope and approval section or explain why the change qualifies f…

Full details: Docstring Coverage

Explanation

Docstring coverage is 44.44% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 9 functions across 4 files. (1 skipped: 1 unsupported.)

✨ Finishing Touches 💡 2

📝 Generate docstrings 💡

• Commit to this branch
• Create a new PR

🛠️ Fix failing CI checks 💡

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

_{Comment @coderabbitai help to get the list of available commands.}