Skip to content

fix(browser): retire durable tab rows whose browser never returns#111307

Merged
steipete merged 6 commits into
openclaw:mainfrom
Yigtwxx:fix/browser-retire-unrecoverable-tab-rows
Jul 21, 2026
Merged

fix(browser): retire durable tab rows whose browser never returns#111307
steipete merged 6 commits into
openclaw:mainfrom
Yigtwxx:fix/browser-retire-unrecoverable-tab-rows

Conversation

@Yigtwxx

@Yigtwxx Yigtwxx commented Jul 19, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

What Problem This Solves

Resolves a problem where a user whose browser disappears — closed for good, moved to a different cdpUrl, a laptop that never wakes on the same port — permanently loses the ability to open browser tabs on that profile.

Durable session-tab cleanup defers whenever it cannot prove ownership of a tab. When /json/version fails because the browser is gone, the tab's tracking row is kept for a later retry, and nothing in the subsystem ever removes a row by age. The sweep runs by default every 5 minutes, so those rows are re-claimed, fail, warn, and defer again — forever.

The tracking store has a hard 5,000-row cap with reject-new and no eviction fallback. Once unreachable rows fill it, tracking a new tab throws, and the compensation path closes the tab the user just opened and rethrows. From then on every browser open on that profile opens a tab, closes it again, and errors, with no self-healing path.

Why This Change Was Made

The retry is now bounded. When a close attempt reports the target unavailable and the tab has gone unused past a retire window, the row is dropped instead of deferred again:

if (now - tab.lastUsedAt >= BROWSER_TAB_UNREACHABLE_RETIRE_MS) {
  params.onWarn?.(`retired unreachable tracked browser tab ${tab.nativeTargetId}: ${outcome.reason}`);
  deleteClaimedTab(tab, params.onWarn);
  return 0;
}

Chosen over a namespace defaultTtlMs — which OpenKeyedStoreOptions does support (plugin-state-store.types.ts:53) — because a TTL also expires rows for tabs that are alive and reachable, silently giving up cleanup on them. This branch only fires on a cleanup attempt that already failed to prove ownership, so healthy tabs are untouched.

The window is 24h and deliberately generous: a laptop asleep overnight or a browser restart must not drop tracking. A browser returning after that long almost always carries a fresh browserInstanceFingerprint, which retires the row through the existing ownership-mismatch path anyway, so the row's remaining value is close to nil.

closeTrackedBrowserTabsForSessions now accepts now like sweepTrackedBrowserTabs already did, so lifecycle cleanup can be exercised on a coherent clock.

Non-goal: this does not add a config key. The retire window is a constant, in keeping with the recent config-surface reduction.

The second commit is a pure refactor with no behavior change, needed to stay under the max-lines budget: session-tab-registry.ts sat at 699 of 700 lines and the durable registry test at 982 of 1000, so the fix and its test pushed both over. Cleanup claim bookkeeping moved to session-tab-cleanup-claim.ts and the test shapes to session-tab-registry.sqlite.test-helpers.ts, matching the existing *.test-helpers.ts convention in that directory.

User Impact

A browser that never comes back no longer bricks tab tracking for its profile. Previously the only recovery was manually clearing plugin state; now the rows retire on their own and browser open keeps working. Users whose browser is merely restarting or asleep see no change — tracking survives, as before.

Evidence

Live-browser proof

Real Chrome, real CDP, real SQLite state directory, real registry code. The only
injected input is now — the parameter sweepTrackedBrowserTabs already accepts;
the alternative is waiting 24 real hours. Nothing is mocked or stubbed.

It runs as two processes on purpose. A browser that stays away for a day outlives
the OpenClaw process, so the second phase starts fresh: the in-memory active-tab
set is empty and the row is read back from SQLite, exactly as after a restart.

Phase 1 — a real browser produces a durable row, then dies:

[phase1] real Chrome tab -> resolveCdpTabOwnership status=durable
[phase1] durable row written to real SQLite: true
[phase1] Chrome killed; CDP reachable=false
[phase1] ownership on dead browser -> {"status":"non-durable","reason":"browser-identity-lookup-failed"}
[phase1] exiting so the in-memory active-tab set dies with the process

Phase 2 — a fresh process sweeps, using the same idleMs / maxTabsPerSession
the production sweep passes (session-tab-cleanup.ts:44):

[phase2] fresh process; row survived restart: true
[phase2] active-tab set is empty after restart: true
[phase2] sweep at T0+3h  -> row still tracked: true (expected: true, retry not retire)
[phase2] sweep at T0+25h -> row retired: true (expected: true)
         | warn: retired unreachable tracked browser tab <TARGET_ID>: browser-identity-lookup-failed

browser-identity-lookup-failed is the genuine outcome of probing a killed
browser — it is what closeTrackedCdpTarget maps to {status:"unavailable"}
(cdp.helpers.ts:406-410), so the row reaches the new branch the way it would in
the field, not because a status was handed to it.

Two limits I want to state plainly rather than imply otherwise:

  • The tab is created with a raw CDP PUT /json/new rather than through the
    browser open tool action, which would require standing up the browser control
    server. The tab, the ownership probe, the registry write and the sweep are all
    production code; the entry point is one level below the tool boundary.
  • The 5000-row reject-new cap recovery is argued from the code, not
    demonstrated    . Showing it honestly would need 5000 durable rows each with a
    distinct real browser fingerprint, and writing filler rows programmatically
    would make the artifact fake. What is demonstrated above is the mechanism that
    stops the cap filling: the unreachable row retires instead of being retried
    forever.

Regression tests

New test pins both edges of the window — the row survives at RETIRE_MS - 1 and is gone at RETIRE_MS:

✓ retires a durable tab whose browser stays unreachable past the retire age

Test Files  4 passed (4)
     Tests  160 passed (160)

(session-tab-registry.sqlite.test.ts, session-tab-registry.test.ts, extensions/browser/index.test.ts, browser-tool.test.ts)

The new test is load-bearing, not just passing: neutralising the retire condition to if (false && ...) fails it on the terminal assertion, with ["NATIVE-gone"] still in the store.

Local gates: run-tsgo.mjs clean · run-oxlint.mjs extensions/browser clean · oxfmt --check clean · check-max-lines-ratchet.mjs clean · check-deadcode-exports.mjs 0 unused exports.

Four macOS-only failures elsewhere in extensions/browser/src/browser/ (Info.plist / LaunchServices / com.microsoft.edgemac) reproduce identically on a stashed tree, so they are pre-existing on Windows and unrelated to this change.

One fixture change to call out: "retries pending lifecycle cleanup even when normal sweeps filter the session" tracked at now: 1_000 but called lifecycle cleanup on the wall clock, which made the row appear decades idle once age started mattering. Passing now: 2_000 keeps the test's original intent — a pending lifecycle cleanup survives a transient failure — on a single clock.

Follow-up from #110797

This is the second of two findings I raised while reviewing #110797. The first — CDP's No target with given id found not matching the ignorable-close classification — landed in that PR (cdp.helpers.ts:463). This one was flagged as a P1 there as well and is still open on main.

AI-assisted: investigation, patch, and tests were produced with AI assistance and verified locally as described above.

@Yigtwxx
fix(browser): retire durable tab rows whose browser never returns
37b3ffd 
Durable cleanup defers whenever ownership cannot be proven, so a browser
that never comes back at the same cdpUrl leaves its rows behind forever:
each sweep re-claims them, fails the identity lookup, warns, and defers
again. Nothing in the subsystem removes a row by age.

The `browser.session-tabs` namespace is opened with a 5000-row cap and
`reject-new`, so once those rows accumulate to the cap, tracking a new tab
throws PLUGIN_STATE_LIMIT_EXCEEDED. That propagates into the compensation
path in browser-tool-session-tabs.ts, which closes the tab the user just
opened and rethrows -- every `browser open` on that profile then opens a
tab, closes it again, and errors, with no self-healing path.

Bound the retry: when a close attempt reports the target unavailable and
the tab has been unused for longer than the retire window, drop the row
instead of deferring again. A browser returning after that long almost
always carries a fresh instance fingerprint, which retires the row through
the ownership-mismatch path anyway.

closeTrackedBrowserTabsForSessions now accepts `now` like the sweep does,
so lifecycle cleanup can be exercised on a coherent clock.
@openclaw-barnacle openclaw-barnacle Bot added docs Improvements or additions to documentation size: S triage: needs-pr-context Candidate: external PR body lacks required problem context or evidence. labels Jul 19, 2026
@clawsweeper clawsweeper Bot added rating: 🧂 unranked krab Not merge-ready due to missing proof or serious correctness/safety concerns. status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask. P2 Normal backlog priority with limited blast radius. merge-risk: 🚨 compatibility 🚨 May break existing users, config, migrations, defaults, or upgrade paths. labels Jul 19, 2026
@clawsweeper

clawsweeper Bot commented Jul 19, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Codex review: needs maintainer review before merge. Reviewed July 20, 2026, 3:38 PM ET / 19:38 UTC.

Summary
The branch retires durable browser-tab tracking rows after 24 hours of repeated unavailable-browser cleanup attempts, refactors cleanup claim/test helpers, adds regression coverage, and documents the bounded retry behavior.

PR surface: Source +125, Tests -38, Docs +3. Total +90 across 6 files.

Reproducibility: yes. at source level and through the contributor's supplied live run: a durable row for a browser that remains unavailable is retried rather than removed, while the proposed branch retires it at the explicit threshold. I did not independently execute the browser scenario in this read-only review.

Review metrics: none identified.

Stored data model
Persistent data-model change detected: serialized state: extensions/browser/src/browser/session-tab-cleanup-claim.ts, serialized state: extensions/browser/src/browser/session-tab-registry.sqlite.test-helpers.ts, serialized state: extensions/browser/src/browser/session-tab-registry.sqlite.test.ts, serialized state: extensions/browser/src/browser/session-tab-registry.ts, unknown-data-model-change: extensions/browser/src/browser/session-tab-cleanup-claim.ts, unknown-data-model-change: extensions/browser/src/browser/session-tab-registry.sqlite.test-helpers.ts, and 2 more. Confirm migration or upgrade compatibility proof before merge.

Merge readiness
Overall: 🦞 diamond lobster
Proof: 🦞 diamond lobster
Patch quality: 🦞 diamond lobster
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Risk before merge

  • [P1] Merging changes a prior eventual-cleanup expectation: a browser that remains unavailable for 24 hours loses its durable tracking row, so a later return on the same instance will no longer be eligible for OpenClaw cleanup.
  • [P1] The fixed window is intentionally not configurable; maintainers need to accept that tradeoff rather than treating it as a purely mechanical bug fix.

Maintainer options:

  1. Merge with the bounded-retention contract (recommended)
    Accept that unavailable rows retire after 24 hours and rely on the focused regression test plus the supplied real Chrome/SQLite proof for the self-healing path.
  2. Pause for retention-policy confirmation
    Keep the PR open until the durable-tab owner confirms whether preserving eventual cleanup beyond a day is a supported compatibility requirement.

Next step before merge

  • [P2] No narrow repair is indicated; a maintainer must choose the durable-row retention contract before this otherwise proof-backed patch can land.

Maintainer decision needed

  • Question: Should durable browser-tab rows be retired after 24 hours of genuine unavailable-browser cleanup failures, accepting that a same-instance browser returning later will no longer be tracked for cleanup?
  • Rationale: The patch is internally coherent and proof-backed, but the correct retention horizon is a product compatibility decision: it balances self-healing capacity against eventual cleanup for long-offline user browsers.
  • Likely owner: FMLS — FMLS introduced the current durable ownership and cleanup model in the merged restart-cleanup work, so they are best positioned to confirm its intended long-outage contract.
  • Options:
    • Adopt bounded retirement (recommended): Merge the 24-hour retirement policy to prevent unreachable rows from permanently consuming the capped durable store.
    • Preserve indefinite retry: Keep the existing retry-forever behavior and pursue a separately approved capacity or operator-recovery design without dropping durable rows by age.

Security
Cleared: The supplied diff changes browser-plugin cleanup, tests, and docs without adding dependencies, workflows, package resolution, secrets access, or other concrete supply-chain/security exposure.

Review details

Best possible solution:

Adopt the bounded-retirement behavior only if maintainers explicitly prefer preventing durable-store exhaustion over preserving cleanup eligibility for a browser that returns after more than 24 hours; otherwise retain indefinite retry and pursue a separately approved capacity strategy.

Do we have a high-confidence way to reproduce the issue?

Yes, at source level and through the contributor's supplied live run: a durable row for a browser that remains unavailable is retried rather than removed, while the proposed branch retires it at the explicit threshold. I did not independently execute the browser scenario in this read-only review.

Is this the best way to solve the issue?

Unclear until maintainers choose the retention contract. The branch is a narrow implementation of bounded retirement, but indefinite retry versus 24-hour row removal is a compatibility decision rather than a correctness detail.

AGENTS.md: unclear because the file could not be read completely.

Codex review notes: model internal, reasoning high; reviewed against e2bb04328f5c.

Label changes

Label justifications:

  • P2: The change addresses a real browser workflow that can eventually block new tracked tabs, but it is not an emergency runtime or security failure.
  • merge-risk: 🚨 compatibility: A fixed 24-hour retirement window intentionally stops tracking some previously retained durable rows after long browser outages.
  • rating: 🦞 diamond lobster: Overall readiness is 🦞 diamond lobster; proof is 🦞 diamond lobster and patch quality is 🦞 diamond lobster.
  • status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (live_output): The PR supplies a credible after-fix two-process real Chrome, CDP, and SQLite demonstration of the unavailable-browser path, including below- and above-threshold outcomes; it does not prove the 5,000-row cap end-to-end, but it directly proves the new retirement mechanism.
  • proof: sufficient: Contributor real behavior proof is sufficient. The PR supplies a credible after-fix two-process real Chrome, CDP, and SQLite demonstration of the unavailable-browser path, including below- and above-threshold outcomes; it does not prove the 5,000-row cap end-to-end, but it directly proves the new retirement mechanism.
Evidence reviewed

PR surface:

Source +125, Tests -38, Docs +3. Total +90 across 6 files.

View PR surface stats
Area Files Added Removed Net
Source 4 201 76 +125
Tests 1 34 72 -38
Docs 1 4 1 +3
Config 0 0 0 0
Generated 0 0 0 0
Other 0 0 0 0
Total 6 239 149 +90

What I checked:

Likely related people:

  • FMLS: Authored the merged restart-safe durable-tab registry work that established the ownership, SQLite, and cleanup-claim behavior this follow-up changes. (role: durable browser-tab registry feature introducer; confidence: high; commits: 4074e0cae15c; files: extensions/browser/src/browser/session-tab-registry.ts, extensions/browser/src/browser/session-tab-store.ts)
What the crustacean ranks mean
  • 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
  • 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
  • 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
  • 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
  • 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
  • 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
  • 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works
  • ClawSweeper keeps one durable marker-backed review comment per issue or PR.
  • Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
  • A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
  • PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
  • Maintainers can also comment @clawsweeper review to request a fresh review only.
  • Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
  • Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
  • Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.
Review history (5 earlier review cycles)
  • reviewed 2026-07-19T08:22:05.691Z sha 37b3ffd :: needs real behavior proof before merge. :: none
  • reviewed 2026-07-19T08:56:39.552Z sha b9230c6 :: needs real behavior proof before merge. :: none
  • reviewed 2026-07-19T10:43:39.329Z sha b9230c6 :: needs maintainer review before merge. :: none
  • reviewed 2026-07-19T11:05:29.339Z sha f78eeee :: needs maintainer review before merge. :: none
  • reviewed 2026-07-19T11:47:43.630Z sha f78eeee :: needs maintainer review before merge. :: none

@Yigtwxx
refactor(browser): split session tab cleanup claim and test harness
b9230c6 
check-lint failed on max-lines: session-tab-registry.ts was at 699 of its
700-line budget and the durable registry test at 982 of 1000, so the retire
branch and its regression test pushed both over.

Extract the cleanup claim bookkeeping (claim, ownership match, delete) into
session-tab-cleanup-claim.ts, and the durable registry test shapes into
session-tab-registry.sqlite.test-helpers.ts, matching the existing
*.test-helpers.ts convention in this directory. No behavior change.
@openclaw-barnacle openclaw-barnacle Bot added size: M and removed size: S triage: needs-pr-context Candidate: external PR body lacks required problem context or evidence. labels Jul 19, 2026
@clawsweeper clawsweeper Bot added rating: 🦪 silver shellfish Thin PR readiness signal; proof, validation, or implementation needs work. and removed rating: 🧂 unranked krab Not merge-ready due to missing proof or serious correctness/safety concerns. labels Jul 19, 2026
@Yigtwxx

Yigtwxx commented Jul 19, 2026

Copy link
Copy Markdown
Contributor Author

Added the live-browser evidence requested in the review — see the Live-browser proof section in the PR body.

Real Chrome, real CDP, real SQLite state dir, real registry code; the only injected input is now, the parameter sweepTrackedBrowserTabs already takes. It runs as two processes deliberately, because a browser that stays away for a day outlives the OpenClaw process: phase 2 starts fresh, with an empty in-memory active-tab set, and reads the row back from SQLite the way a restarted gateway would.

The chain the review asked for:

  • unavailable row: killing Chrome makes resolveCdpTabOwnership return browser-identity-lookup-failed, which closeTrackedCdpTarget maps to {status:"unavailable"} (cdp.helpers.ts:406-410) — the row reaches the new branch on a genuine outcome, not an injected status
  • below the threshold: sweep at T0+3h leaves the row tracked (retry, not retire)
  • across the threshold: sweep at T0+25h retires it, emitting retired unreachable tracked browser tab <id>: browser-identity-lookup-failed
  • a later open stays tracked, and the relaunched browser carries a different browserInstanceFingerprint

Two limits stated in the body rather than papered over: the tab is created via raw CDP PUT /json/new rather than through the browser open tool action (which needs the browser control server running), and the 5000-row cap recovery is argued from the code rather than demonstrated — showing it honestly would need 5000 real browser fingerprints, and generating filler rows would have made the artifact fake. What is demonstrated is the mechanism that keeps the cap from filling.

On the retention question for @FMLS: the 24h window is a policy choice and I have no attachment to the specific number — it is a single constant (BROWSER_TAB_UNREACHABLE_RETIRE_MS) and I am happy to change it, make it configurable, or drop the change entirely if indefinite retry is the intended contract.

@clawsweeper re-review

@clawsweeper

clawsweeper Bot commented Jul 19, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

@clawsweeper clawsweeper Bot added proof: sufficient ClawSweeper judged the real behavior proof convincing. rating: 🐚 platinum hermit Good normal PR readiness with ordinary maintainer review expected. status: 👀 ready for maintainer look ClawSweeper has no concrete contributor-facing blocker left for this PR. and removed rating: 🦪 silver shellfish Thin PR readiness signal; proof, validation, or implementation needs work. status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask. labels Jul 19, 2026
@clawsweeper clawsweeper Bot added rating: 🦞 diamond lobster Very strong PR readiness with only minor maintainer review expected. and removed rating: 🐚 platinum hermit Good normal PR readiness with ordinary maintainer review expected. labels Jul 21, 2026
@github-actions github-actions Bot mentioned this pull request Jul 21, 2026
Open
@steipete steipete self-assigned this Jul 21, 2026
@steipete

steipete commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

Maintainer review accepts the fixed 24-hour unavailable-and-idle retirement window. The cleanup owner has the authoritative row, current clock, and real ownership outcome; a namespace TTL or reject-new eviction would remove rows without proving ownership, while a new retry counter would expand persistent state without avoiding the policy decision.

I added one focused preparation regression: an over-age unavailable probe now races with touchSessionBrowserTab, and the test proves the touch revokes the sweep claim so the updated row survives without stale cleanup metadata. The final merged-with-main tree passes the five focused browser files, 158 tests total, plus formatting and git diff --check.

Codex autoreview raised one false-positive finding claiming the lifecycle now override was not forwarded. It is forwarded by the existing { ...params, cleanupKind: "lifecycle" } call into closeTrackedTabs, which resolves params.now ?? Date.now() and passes that value to durable cleanup. The focused lifecycle test and final 158-test run cover this path, so no redundant code change was made.

Provenance: the non-converging unavailable-row behavior and 5,000-entry reject-new store were introduced by #110797 (@FMLS, merged by @steipete on 2026-07-19). This PR completes the bounded-retirement move identified during that landing review while preserving browser-instance fingerprint checks.

@clawsweeper

clawsweeper Bot commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

ClawSweeper status: review started.

I am starting a fresh review of this pull request: fix(browser): retire durable tab rows whose browser never returns This is item 1/1 in the current shard. Shard 0/1.

This placeholder means the worker is alive and reading the current context. I will edit this same comment with the actual review when the claws are done clicking.

Crustacean status: shell secured, claws on keyboard, evidence pebbles being sorted.

@steipete
steipete merged commit 1096b74 into openclaw:main Jul 21, 2026
107 checks passed
@steipete

steipete commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

Merged via squash.

@github-actions github-actions Bot mentioned this pull request Jul 21, 2026
Open
github-actions Bot pushed a commit to Desicool/openclaw that referenced this pull request Jul 22, 2026
@Yigtwxx @steipete
fix(browser): retire durable tab rows whose browser never returns (op…
d66acd5 
…enclaw#111307)

* fix(browser): retire durable tab rows whose browser never returns

Durable cleanup defers whenever ownership cannot be proven, so a browser
that never comes back at the same cdpUrl leaves its rows behind forever:
each sweep re-claims them, fails the identity lookup, warns, and defers
again. Nothing in the subsystem removes a row by age.

The `browser.session-tabs` namespace is opened with a 5000-row cap and
`reject-new`, so once those rows accumulate to the cap, tracking a new tab
throws PLUGIN_STATE_LIMIT_EXCEEDED. That propagates into the compensation
path in browser-tool-session-tabs.ts, which closes the tab the user just
opened and rethrows -- every `browser open` on that profile then opens a
tab, closes it again, and errors, with no self-healing path.

Bound the retry: when a close attempt reports the target unavailable and
the tab has been unused for longer than the retire window, drop the row
instead of deferring again. A browser returning after that long almost
always carries a fresh instance fingerprint, which retires the row through
the ownership-mismatch path anyway.

closeTrackedBrowserTabsForSessions now accepts `now` like the sweep does,
so lifecycle cleanup can be exercised on a coherent clock.

* refactor(browser): split session tab cleanup claim and test harness

check-lint failed on max-lines: session-tab-registry.ts was at 699 of its
700-line budget and the durable registry test at 982 of 1000, so the retire
branch and its regression test pushed both over.

Extract the cleanup claim bookkeeping (claim, ownership match, delete) into
session-tab-cleanup-claim.ts, and the durable registry test shapes into
session-tab-registry.sqlite.test-helpers.ts, matching the existing
*.test-helpers.ts convention in this directory. No behavior change.

* test(browser): protect unreachable retirement races

Co-authored-by: Yigtwxx <[email protected]>

---------

Co-authored-by: Peter Steinberger <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

@steipete steipete

Labels

docs Improvements or additions to documentation merge-risk: 🚨 compatibility 🚨 May break existing users, config, migrations, defaults, or upgrade paths. P2 Normal backlog priority with limited blast radius. proof: sufficient ClawSweeper judged the real behavior proof convincing. rating: 🦞 diamond lobster Very strong PR readiness with only minor maintainer review expected. size: M status: 👀 ready for maintainer look ClawSweeper has no concrete contributor-facing blocker left for this PR.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@Yigtwxx @steipete