fix(web): settle the connection database open when IndexedDB reports "blocked" by Jardo-51 · Pull Request #5121 · pingdotgg/t3code

Jardo-51 · 2026-07-31T13:17:31Z

What Changed

openDatabase in apps/web/src/connection/storage.ts now registers a blocked listener on the indexedDB.open request, resuming with the same ConnectionTransientError the existing error path uses. A second commit closes the database handle if the request later succeeds after having reported blocked.

Two files, 35 lines including the test.

Why

IDBOpenDBRequest fires blocked — instead ofsuccess or error — when another connection holds the database open and the open request needs a version change. openDatabase registered only upgradeneeded, error, and success, so in that case resume is never called and the Effect.callback never settles. There is no timeout on it, so it hangs for the lifetime of the page.

Scope of the claim, up front: this is spec-driven hardening for a path I have not observed in the wild. I originally opened this believing it explained a splash-screen hang I was chasing. It did not — that turned out to be a corrupted browser HTTP disk cache, written up in #5116. The first version of this description claimed a multi-tab reproduction and a live verification against a wedged profile; I performed neither. Both are removed. The full correction is in the comment thread below and in #5116.

What remains is a real hole regardless of how often it is reached. The realistic trigger is a DATABASE_VERSION bump: every existing user's next open becomes an upgrade open, and any user with a second tab still holding a connection at that moment gets blocked and hangs — no error, no retry, no log. That version has already been bumped twice (v2, then v4 in #3795), so this is a predictable consequence of each schema change rather than an exotic race.

The second commit fixes a related leak found in review: blocked does not cancel the request, so a later success handed back an IDBDatabase that nothing owned or closed — a connection held for the lifetime of the page, blocking every future version change. The callback now tracks whether it settled and closes the late handle.

Scope

Deliberately narrow. The connection is held for the lifetime of the page via Effect.acquireRelease with no versionchange handler, so an older tab still blocks a newer tab's upgrade — the newer tab now reports it cleanly rather than hanging, but the upgrade cannot proceed until the old tab closes. Fixing that means adding versionchange → database.close(), which first needs the read/write helpers hardened, since database.transaction() throws synchronously on a closed handle and would surface as a defect rather than a typed failure. Happy to do it as a follow-up; kept out of here to keep the change small.

Testing

New test dispatches blocked at a stubbed indexedDB.open and asserts the effect fails. openDatabase is exported for it, matching how makeCatalogStore / makeCatalogBackend are already exposed to the same test file.
The test is not vacuous: with the blocked handler removed it hangs and times out at 60s, reproducing the non-settling request in the harness. With the handler it passes.
The second commit's late-success guard has its own test; removing the guard fails it.
vp test run --project unit src/connection/storage.test.ts → 5 passed.
tsgo --noEmit on apps/web → exit 0. vp lint on both files → clean.

Not verified in a browser — see the scope note above.

Checklist

This PR is small and focused
I explained what changed and why
I included before/after screenshots for any UI changes — no visual change; the only user-visible difference is that an existing error state is reached instead of an indefinite hang
I included a video for animation/interaction changes — n/a

…"blocked" `openDatabase` registered only `upgradeneeded`, `error`, and `success` on the `indexedDB.open` request. `blocked` fires *instead of* `success`/`error` when another connection holds the database open and the open needs a version change, so the `Effect.callback` never resumed and the web client hung forever on the splash screen — no error, no timeout, no retry, and no network activity or CPU use to diagnose it from. The hung tab never released its own connection either, so every subsequent load blocked as well. Resume with the existing transient error instead, so the failure surfaces in the UI and can be retried. Covered by a test that dispatches `blocked`; without the handler that test times out rather than failing. This does not address the related gap that the connection is held for the lifetime of the page with no `versionchange` handler, so an older tab still blocks a newer tab's upgrade — the newer tab now reports it cleanly instead of hanging, but the upgrade cannot proceed until the old tab closes. Upstream issue: pingdotgg#5116 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CkwXzkvT38LpY5LTfareGs (cherry picked from commit c99c2bc)

coderabbitai · 2026-07-31T13:17:46Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 8ef354d7-47ac-47c0-9bac-9b1b12a185b8

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

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

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

macroscopeapp · 2026-07-31T13:24:37Z

Approvability

Verdict: Approved 7fbb4fc

Straightforward bug fix that handles IndexedDB's 'blocked' event - converts an indefinite hang into a clear error message with user guidance. Changes are self-contained, well-tested, and address a specific edge case without broader side effects.

^{You can customize Macroscope's approvability policy. Learn more.}

Review catch: `blocked` does not cancel the open request. When the blocking connection goes away the request still completes and fires `success`, but the `Effect.callback` has already failed, so the second `resume` is a no-op and the `IDBDatabase` never reaches `acquireRelease` to be closed. That leaked connection then holds the database open for the lifetime of the page and blocks every later version change — the same deadlock the `blocked` handler was added to break. Track whether the callback has settled and close the handle instead of leaking it. Aborting the request would be the tidier fix, but `IDBOpenDBRequest` inherits from `IDBRequest`, which has no `abort()`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CkwXzkvT38LpY5LTfareGs

Jardo-51 · 2026-08-01T10:49:19Z

Rescoping this based on further investigation — full detail in #5116.

Short version: the blocked handler is correct and worth having, but it does not fix the splash hang that motivated it, and two claims in my PR description don't hold.

The reachability argument.blocked fires only when an open needs a version change and another connection is open. DATABASE_VERSION has been 4 since #3795 (2026-07-09), so any client built since then performs same-version opens, which never open a version-change transaction and therefore can never emit blocked. The path was unreachable in my environment.

Corrections to the description above:

"It reproduces with several app tabs open in one browser profile" — I never ran that. I only ever had a single tab open during the investigation. Those steps were reasoned from the spec, not executed.
"Verified against a live wedged browser profile: the tab now reports the error instead of hanging" — this doesn't hold either. The hang reproduced again with this patch applied, single tab. The one clean boot I saw was coincidence, matching the "deleting IndexedDB bought exactly one clean boot" note already in the description.

What the patch is still good for. A blocked event with no listener genuinely never settles — that's a real hole regardless of how it's reached. It matters for anyone upgrading a database created before #3795 (v2 → v4), and for the next DATABASE_VERSION bump. The versionchange follow-up noted under Scope is the more broadly useful one.

So: suggest dropping the Fixes #5116 link and taking this as defensive hardening on its own merits. The actual splash hang looks like the unbounded auth bootstrap behind the root route's async beforeLoad — no timeout on fetchSessionState, and no defaultPendingComponent, so any stall there leaves the static #boot-shell markup on screen with no error, retry, or log. Trace is in #5116.

Let me know whether you'd prefer I retitle this one and open a separate issue for the auth gate, or close it in favour of a combined fix.

t3dotgg · 2026-08-28T12:55:00Z

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

The author states that this IndexedDB blocked path was not observed and did not cause the splash-screen failure that prompted the PR. The remaining version-upgrade case is too theoretical to keep in the active backlog.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed.

Jardo-51 · 2026-07-31T13:17:31Z

What Changed

openDatabase in apps/web/src/connection/storage.ts now registers a blocked listener on the indexedDB.open request, resuming with the same ConnectionTransientError the existing error path uses. A second commit closes the database handle if the request later succeeds after having reported blocked.

Two files, 35 lines including the test.

Why

IDBOpenDBRequest fires blocked — instead ofsuccess or error — when another connection holds the database open and the open request needs a version change. openDatabase registered only upgradeneeded, error, and success, so in that case resume is never called and the Effect.callback never settles. There is no timeout on it, so it hangs for the lifetime of the page.

Scope of the claim, up front: this is spec-driven hardening for a path I have not observed in the wild. I originally opened this believing it explained a splash-screen hang I was chasing. It did not — that turned out to be a corrupted browser HTTP disk cache, written up in #5116. The first version of this description claimed a multi-tab reproduction and a live verification against a wedged profile; I performed neither. Both are removed. The full correction is in the comment thread below and in #5116.

What remains is a real hole regardless of how often it is reached. The realistic trigger is a DATABASE_VERSION bump: every existing user's next open becomes an upgrade open, and any user with a second tab still holding a connection at that moment gets blocked and hangs — no error, no retry, no log. That version has already been bumped twice (v2, then v4 in #3795), so this is a predictable consequence of each schema change rather than an exotic race.

The second commit fixes a related leak found in review: blocked does not cancel the request, so a later success handed back an IDBDatabase that nothing owned or closed — a connection held for the lifetime of the page, blocking every future version change. The callback now tracks whether it settled and closes the late handle.

Scope

Deliberately narrow. The connection is held for the lifetime of the page via Effect.acquireRelease with no versionchange handler, so an older tab still blocks a newer tab's upgrade — the newer tab now reports it cleanly rather than hanging, but the upgrade cannot proceed until the old tab closes. Fixing that means adding versionchange → database.close(), which first needs the read/write helpers hardened, since database.transaction() throws synchronously on a closed handle and would surface as a defect rather than a typed failure. Happy to do it as a follow-up; kept out of here to keep the change small.

Testing

New test dispatches blocked at a stubbed indexedDB.open and asserts the effect fails. openDatabase is exported for it, matching how makeCatalogStore / makeCatalogBackend are already exposed to the same test file.
The test is not vacuous: with the blocked handler removed it hangs and times out at 60s, reproducing the non-settling request in the harness. With the handler it passes.
The second commit's late-success guard has its own test; removing the guard fails it.
vp test run --project unit src/connection/storage.test.ts → 5 passed.
tsgo --noEmit on apps/web → exit 0. vp lint on both files → clean.

Not verified in a browser — see the scope note above.

Checklist

This PR is small and focused
I explained what changed and why
I included before/after screenshots for any UI changes — no visual change; the only user-visible difference is that an existing error state is reached instead of an indefinite hang
I included a video for animation/interaction changes — n/a

…"blocked" `openDatabase` registered only `upgradeneeded`, `error`, and `success` on the `indexedDB.open` request. `blocked` fires *instead of* `success`/`error` when another connection holds the database open and the open needs a version change, so the `Effect.callback` never resumed and the web client hung forever on the splash screen — no error, no timeout, no retry, and no network activity or CPU use to diagnose it from. The hung tab never released its own connection either, so every subsequent load blocked as well. Resume with the existing transient error instead, so the failure surfaces in the UI and can be retried. Covered by a test that dispatches `blocked`; without the handler that test times out rather than failing. This does not address the related gap that the connection is held for the lifetime of the page with no `versionchange` handler, so an older tab still blocks a newer tab's upgrade — the newer tab now reports it cleanly instead of hanging, but the upgrade cannot proceed until the old tab closes. Upstream issue: pingdotgg#5116 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CkwXzkvT38LpY5LTfareGs (cherry picked from commit c99c2bc)

coderabbitai · 2026-07-31T13:17:46Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 8ef354d7-47ac-47c0-9bac-9b1b12a185b8

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

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

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

macroscopeapp · 2026-07-31T13:24:37Z

Approvability

Verdict: Approved 7fbb4fc

Straightforward bug fix that handles IndexedDB's 'blocked' event - converts an indefinite hang into a clear error message with user guidance. Changes are self-contained, well-tested, and address a specific edge case without broader side effects.

^{You can customize Macroscope's approvability policy. Learn more.}

Review catch: `blocked` does not cancel the open request. When the blocking connection goes away the request still completes and fires `success`, but the `Effect.callback` has already failed, so the second `resume` is a no-op and the `IDBDatabase` never reaches `acquireRelease` to be closed. That leaked connection then holds the database open for the lifetime of the page and blocks every later version change — the same deadlock the `blocked` handler was added to break. Track whether the callback has settled and close the handle instead of leaking it. Aborting the request would be the tidier fix, but `IDBOpenDBRequest` inherits from `IDBRequest`, which has no `abort()`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CkwXzkvT38LpY5LTfareGs

Jardo-51 · 2026-08-01T10:49:19Z

Rescoping this based on further investigation — full detail in #5116.

Short version: the blocked handler is correct and worth having, but it does not fix the splash hang that motivated it, and two claims in my PR description don't hold.

The reachability argument.blocked fires only when an open needs a version change and another connection is open. DATABASE_VERSION has been 4 since #3795 (2026-07-09), so any client built since then performs same-version opens, which never open a version-change transaction and therefore can never emit blocked. The path was unreachable in my environment.

Corrections to the description above:

"It reproduces with several app tabs open in one browser profile" — I never ran that. I only ever had a single tab open during the investigation. Those steps were reasoned from the spec, not executed.
"Verified against a live wedged browser profile: the tab now reports the error instead of hanging" — this doesn't hold either. The hang reproduced again with this patch applied, single tab. The one clean boot I saw was coincidence, matching the "deleting IndexedDB bought exactly one clean boot" note already in the description.

What the patch is still good for. A blocked event with no listener genuinely never settles — that's a real hole regardless of how it's reached. It matters for anyone upgrading a database created before #3795 (v2 → v4), and for the next DATABASE_VERSION bump. The versionchange follow-up noted under Scope is the more broadly useful one.

So: suggest dropping the Fixes #5116 link and taking this as defensive hardening on its own merits. The actual splash hang looks like the unbounded auth bootstrap behind the root route's async beforeLoad — no timeout on fetchSessionState, and no defaultPendingComponent, so any stall there leaves the static #boot-shell markup on screen with no error, retry, or log. Trace is in #5116.

Let me know whether you'd prefer I retitle this one and open a separate issue for the auth gate, or close it in favour of a combined fix.

t3dotgg · 2026-08-28T12:55:00Z

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

The author states that this IndexedDB blocked path was not observed and did not cause the splash-screen failure that prompted the PR. The remaining version-upgrade case is too theoretical to keep in the active backlog.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed.

Jardo-51 · 2026-07-31T13:17:31Z

What Changed

openDatabase in apps/web/src/connection/storage.ts now registers a blocked listener on the indexedDB.open request, resuming with the same ConnectionTransientError the existing error path uses. A second commit closes the database handle if the request later succeeds after having reported blocked.

Two files, 35 lines including the test.

Why

IDBOpenDBRequest fires blocked — instead ofsuccess or error — when another connection holds the database open and the open request needs a version change. openDatabase registered only upgradeneeded, error, and success, so in that case resume is never called and the Effect.callback never settles. There is no timeout on it, so it hangs for the lifetime of the page.

Scope of the claim, up front: this is spec-driven hardening for a path I have not observed in the wild. I originally opened this believing it explained a splash-screen hang I was chasing. It did not — that turned out to be a corrupted browser HTTP disk cache, written up in #5116. The first version of this description claimed a multi-tab reproduction and a live verification against a wedged profile; I performed neither. Both are removed. The full correction is in the comment thread below and in #5116.

What remains is a real hole regardless of how often it is reached. The realistic trigger is a DATABASE_VERSION bump: every existing user's next open becomes an upgrade open, and any user with a second tab still holding a connection at that moment gets blocked and hangs — no error, no retry, no log. That version has already been bumped twice (v2, then v4 in #3795), so this is a predictable consequence of each schema change rather than an exotic race.

The second commit fixes a related leak found in review: blocked does not cancel the request, so a later success handed back an IDBDatabase that nothing owned or closed — a connection held for the lifetime of the page, blocking every future version change. The callback now tracks whether it settled and closes the late handle.

Scope

Deliberately narrow. The connection is held for the lifetime of the page via Effect.acquireRelease with no versionchange handler, so an older tab still blocks a newer tab's upgrade — the newer tab now reports it cleanly rather than hanging, but the upgrade cannot proceed until the old tab closes. Fixing that means adding versionchange → database.close(), which first needs the read/write helpers hardened, since database.transaction() throws synchronously on a closed handle and would surface as a defect rather than a typed failure. Happy to do it as a follow-up; kept out of here to keep the change small.

Testing

New test dispatches blocked at a stubbed indexedDB.open and asserts the effect fails. openDatabase is exported for it, matching how makeCatalogStore / makeCatalogBackend are already exposed to the same test file.
The test is not vacuous: with the blocked handler removed it hangs and times out at 60s, reproducing the non-settling request in the harness. With the handler it passes.
The second commit's late-success guard has its own test; removing the guard fails it.
vp test run --project unit src/connection/storage.test.ts → 5 passed.
tsgo --noEmit on apps/web → exit 0. vp lint on both files → clean.

Not verified in a browser — see the scope note above.

Checklist

This PR is small and focused
I explained what changed and why
I included before/after screenshots for any UI changes — no visual change; the only user-visible difference is that an existing error state is reached instead of an indefinite hang
I included a video for animation/interaction changes — n/a

…"blocked" `openDatabase` registered only `upgradeneeded`, `error`, and `success` on the `indexedDB.open` request. `blocked` fires *instead of* `success`/`error` when another connection holds the database open and the open needs a version change, so the `Effect.callback` never resumed and the web client hung forever on the splash screen — no error, no timeout, no retry, and no network activity or CPU use to diagnose it from. The hung tab never released its own connection either, so every subsequent load blocked as well. Resume with the existing transient error instead, so the failure surfaces in the UI and can be retried. Covered by a test that dispatches `blocked`; without the handler that test times out rather than failing. This does not address the related gap that the connection is held for the lifetime of the page with no `versionchange` handler, so an older tab still blocks a newer tab's upgrade — the newer tab now reports it cleanly instead of hanging, but the upgrade cannot proceed until the old tab closes. Upstream issue: pingdotgg#5116 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CkwXzkvT38LpY5LTfareGs (cherry picked from commit c99c2bc)

coderabbitai · 2026-07-31T13:17:46Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 8ef354d7-47ac-47c0-9bac-9b1b12a185b8

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

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

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

macroscopeapp · 2026-07-31T13:24:37Z

Approvability

Verdict: Approved 7fbb4fc

Straightforward bug fix that handles IndexedDB's 'blocked' event - converts an indefinite hang into a clear error message with user guidance. Changes are self-contained, well-tested, and address a specific edge case without broader side effects.

^{You can customize Macroscope's approvability policy. Learn more.}

Review catch: `blocked` does not cancel the open request. When the blocking connection goes away the request still completes and fires `success`, but the `Effect.callback` has already failed, so the second `resume` is a no-op and the `IDBDatabase` never reaches `acquireRelease` to be closed. That leaked connection then holds the database open for the lifetime of the page and blocks every later version change — the same deadlock the `blocked` handler was added to break. Track whether the callback has settled and close the handle instead of leaking it. Aborting the request would be the tidier fix, but `IDBOpenDBRequest` inherits from `IDBRequest`, which has no `abort()`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CkwXzkvT38LpY5LTfareGs

Jardo-51 · 2026-08-01T10:49:19Z

Rescoping this based on further investigation — full detail in #5116.

Short version: the blocked handler is correct and worth having, but it does not fix the splash hang that motivated it, and two claims in my PR description don't hold.

The reachability argument.blocked fires only when an open needs a version change and another connection is open. DATABASE_VERSION has been 4 since #3795 (2026-07-09), so any client built since then performs same-version opens, which never open a version-change transaction and therefore can never emit blocked. The path was unreachable in my environment.

Corrections to the description above:

"It reproduces with several app tabs open in one browser profile" — I never ran that. I only ever had a single tab open during the investigation. Those steps were reasoned from the spec, not executed.
"Verified against a live wedged browser profile: the tab now reports the error instead of hanging" — this doesn't hold either. The hang reproduced again with this patch applied, single tab. The one clean boot I saw was coincidence, matching the "deleting IndexedDB bought exactly one clean boot" note already in the description.

What the patch is still good for. A blocked event with no listener genuinely never settles — that's a real hole regardless of how it's reached. It matters for anyone upgrading a database created before #3795 (v2 → v4), and for the next DATABASE_VERSION bump. The versionchange follow-up noted under Scope is the more broadly useful one.

So: suggest dropping the Fixes #5116 link and taking this as defensive hardening on its own merits. The actual splash hang looks like the unbounded auth bootstrap behind the root route's async beforeLoad — no timeout on fetchSessionState, and no defaultPendingComponent, so any stall there leaves the static #boot-shell markup on screen with no error, retry, or log. Trace is in #5116.

Let me know whether you'd prefer I retitle this one and open a separate issue for the auth gate, or close it in favour of a combined fix.

t3dotgg · 2026-08-28T12:55:00Z

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

The author states that this IndexedDB blocked path was not observed and did not cause the splash-screen failure that prompted the PR. The remaining version-upgrade case is too theoretical to keep in the active backlog.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed.

Jardo-51 · 2026-07-31T13:17:31Z

What Changed

openDatabase in apps/web/src/connection/storage.ts now registers a blocked listener on the indexedDB.open request, resuming with the same ConnectionTransientError the existing error path uses. A second commit closes the database handle if the request later succeeds after having reported blocked.

Two files, 35 lines including the test.

Why

IDBOpenDBRequest fires blocked — instead ofsuccess or error — when another connection holds the database open and the open request needs a version change. openDatabase registered only upgradeneeded, error, and success, so in that case resume is never called and the Effect.callback never settles. There is no timeout on it, so it hangs for the lifetime of the page.

Scope of the claim, up front: this is spec-driven hardening for a path I have not observed in the wild. I originally opened this believing it explained a splash-screen hang I was chasing. It did not — that turned out to be a corrupted browser HTTP disk cache, written up in #5116. The first version of this description claimed a multi-tab reproduction and a live verification against a wedged profile; I performed neither. Both are removed. The full correction is in the comment thread below and in #5116.

What remains is a real hole regardless of how often it is reached. The realistic trigger is a DATABASE_VERSION bump: every existing user's next open becomes an upgrade open, and any user with a second tab still holding a connection at that moment gets blocked and hangs — no error, no retry, no log. That version has already been bumped twice (v2, then v4 in #3795), so this is a predictable consequence of each schema change rather than an exotic race.

The second commit fixes a related leak found in review: blocked does not cancel the request, so a later success handed back an IDBDatabase that nothing owned or closed — a connection held for the lifetime of the page, blocking every future version change. The callback now tracks whether it settled and closes the late handle.

Scope

Deliberately narrow. The connection is held for the lifetime of the page via Effect.acquireRelease with no versionchange handler, so an older tab still blocks a newer tab's upgrade — the newer tab now reports it cleanly rather than hanging, but the upgrade cannot proceed until the old tab closes. Fixing that means adding versionchange → database.close(), which first needs the read/write helpers hardened, since database.transaction() throws synchronously on a closed handle and would surface as a defect rather than a typed failure. Happy to do it as a follow-up; kept out of here to keep the change small.

Testing

New test dispatches blocked at a stubbed indexedDB.open and asserts the effect fails. openDatabase is exported for it, matching how makeCatalogStore / makeCatalogBackend are already exposed to the same test file.
The test is not vacuous: with the blocked handler removed it hangs and times out at 60s, reproducing the non-settling request in the harness. With the handler it passes.
The second commit's late-success guard has its own test; removing the guard fails it.
vp test run --project unit src/connection/storage.test.ts → 5 passed.
tsgo --noEmit on apps/web → exit 0. vp lint on both files → clean.

Not verified in a browser — see the scope note above.

Checklist

This PR is small and focused
I explained what changed and why
I included before/after screenshots for any UI changes — no visual change; the only user-visible difference is that an existing error state is reached instead of an indefinite hang
I included a video for animation/interaction changes — n/a

…"blocked" `openDatabase` registered only `upgradeneeded`, `error`, and `success` on the `indexedDB.open` request. `blocked` fires *instead of* `success`/`error` when another connection holds the database open and the open needs a version change, so the `Effect.callback` never resumed and the web client hung forever on the splash screen — no error, no timeout, no retry, and no network activity or CPU use to diagnose it from. The hung tab never released its own connection either, so every subsequent load blocked as well. Resume with the existing transient error instead, so the failure surfaces in the UI and can be retried. Covered by a test that dispatches `blocked`; without the handler that test times out rather than failing. This does not address the related gap that the connection is held for the lifetime of the page with no `versionchange` handler, so an older tab still blocks a newer tab's upgrade — the newer tab now reports it cleanly instead of hanging, but the upgrade cannot proceed until the old tab closes. Upstream issue: pingdotgg#5116 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CkwXzkvT38LpY5LTfareGs (cherry picked from commit c99c2bc)

coderabbitai · 2026-07-31T13:17:46Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 8ef354d7-47ac-47c0-9bac-9b1b12a185b8

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

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

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

macroscopeapp · 2026-07-31T13:24:37Z

Approvability

Verdict: Approved 7fbb4fc

Straightforward bug fix that handles IndexedDB's 'blocked' event - converts an indefinite hang into a clear error message with user guidance. Changes are self-contained, well-tested, and address a specific edge case without broader side effects.

^{You can customize Macroscope's approvability policy. Learn more.}

Review catch: `blocked` does not cancel the open request. When the blocking connection goes away the request still completes and fires `success`, but the `Effect.callback` has already failed, so the second `resume` is a no-op and the `IDBDatabase` never reaches `acquireRelease` to be closed. That leaked connection then holds the database open for the lifetime of the page and blocks every later version change — the same deadlock the `blocked` handler was added to break. Track whether the callback has settled and close the handle instead of leaking it. Aborting the request would be the tidier fix, but `IDBOpenDBRequest` inherits from `IDBRequest`, which has no `abort()`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CkwXzkvT38LpY5LTfareGs

Jardo-51 · 2026-08-01T10:49:19Z

Rescoping this based on further investigation — full detail in #5116.

Short version: the blocked handler is correct and worth having, but it does not fix the splash hang that motivated it, and two claims in my PR description don't hold.

The reachability argument.blocked fires only when an open needs a version change and another connection is open. DATABASE_VERSION has been 4 since #3795 (2026-07-09), so any client built since then performs same-version opens, which never open a version-change transaction and therefore can never emit blocked. The path was unreachable in my environment.

Corrections to the description above:

"It reproduces with several app tabs open in one browser profile" — I never ran that. I only ever had a single tab open during the investigation. Those steps were reasoned from the spec, not executed.
"Verified against a live wedged browser profile: the tab now reports the error instead of hanging" — this doesn't hold either. The hang reproduced again with this patch applied, single tab. The one clean boot I saw was coincidence, matching the "deleting IndexedDB bought exactly one clean boot" note already in the description.

What the patch is still good for. A blocked event with no listener genuinely never settles — that's a real hole regardless of how it's reached. It matters for anyone upgrading a database created before #3795 (v2 → v4), and for the next DATABASE_VERSION bump. The versionchange follow-up noted under Scope is the more broadly useful one.

So: suggest dropping the Fixes #5116 link and taking this as defensive hardening on its own merits. The actual splash hang looks like the unbounded auth bootstrap behind the root route's async beforeLoad — no timeout on fetchSessionState, and no defaultPendingComponent, so any stall there leaves the static #boot-shell markup on screen with no error, retry, or log. Trace is in #5116.

Let me know whether you'd prefer I retitle this one and open a separate issue for the auth gate, or close it in favour of a combined fix.

t3dotgg · 2026-08-28T12:55:00Z

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

The author states that this IndexedDB blocked path was not observed and did not cause the splash-screen failure that prompted the PR. The remaining version-upgrade case is too theoretical to keep in the active backlog.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed.

Jardo-51 · 2026-07-31T13:17:31Z

What Changed

openDatabase in apps/web/src/connection/storage.ts now registers a blocked listener on the indexedDB.open request, resuming with the same ConnectionTransientError the existing error path uses. A second commit closes the database handle if the request later succeeds after having reported blocked.

Two files, 35 lines including the test.

Why

IDBOpenDBRequest fires blocked — instead ofsuccess or error — when another connection holds the database open and the open request needs a version change. openDatabase registered only upgradeneeded, error, and success, so in that case resume is never called and the Effect.callback never settles. There is no timeout on it, so it hangs for the lifetime of the page.

Scope of the claim, up front: this is spec-driven hardening for a path I have not observed in the wild. I originally opened this believing it explained a splash-screen hang I was chasing. It did not — that turned out to be a corrupted browser HTTP disk cache, written up in #5116. The first version of this description claimed a multi-tab reproduction and a live verification against a wedged profile; I performed neither. Both are removed. The full correction is in the comment thread below and in #5116.

What remains is a real hole regardless of how often it is reached. The realistic trigger is a DATABASE_VERSION bump: every existing user's next open becomes an upgrade open, and any user with a second tab still holding a connection at that moment gets blocked and hangs — no error, no retry, no log. That version has already been bumped twice (v2, then v4 in #3795), so this is a predictable consequence of each schema change rather than an exotic race.

The second commit fixes a related leak found in review: blocked does not cancel the request, so a later success handed back an IDBDatabase that nothing owned or closed — a connection held for the lifetime of the page, blocking every future version change. The callback now tracks whether it settled and closes the late handle.

Scope

Deliberately narrow. The connection is held for the lifetime of the page via Effect.acquireRelease with no versionchange handler, so an older tab still blocks a newer tab's upgrade — the newer tab now reports it cleanly rather than hanging, but the upgrade cannot proceed until the old tab closes. Fixing that means adding versionchange → database.close(), which first needs the read/write helpers hardened, since database.transaction() throws synchronously on a closed handle and would surface as a defect rather than a typed failure. Happy to do it as a follow-up; kept out of here to keep the change small.

Testing

New test dispatches blocked at a stubbed indexedDB.open and asserts the effect fails. openDatabase is exported for it, matching how makeCatalogStore / makeCatalogBackend are already exposed to the same test file.
The test is not vacuous: with the blocked handler removed it hangs and times out at 60s, reproducing the non-settling request in the harness. With the handler it passes.
The second commit's late-success guard has its own test; removing the guard fails it.
vp test run --project unit src/connection/storage.test.ts → 5 passed.
tsgo --noEmit on apps/web → exit 0. vp lint on both files → clean.

Not verified in a browser — see the scope note above.

Checklist

This PR is small and focused
I explained what changed and why
I included before/after screenshots for any UI changes — no visual change; the only user-visible difference is that an existing error state is reached instead of an indefinite hang
I included a video for animation/interaction changes — n/a

…"blocked" `openDatabase` registered only `upgradeneeded`, `error`, and `success` on the `indexedDB.open` request. `blocked` fires *instead of* `success`/`error` when another connection holds the database open and the open needs a version change, so the `Effect.callback` never resumed and the web client hung forever on the splash screen — no error, no timeout, no retry, and no network activity or CPU use to diagnose it from. The hung tab never released its own connection either, so every subsequent load blocked as well. Resume with the existing transient error instead, so the failure surfaces in the UI and can be retried. Covered by a test that dispatches `blocked`; without the handler that test times out rather than failing. This does not address the related gap that the connection is held for the lifetime of the page with no `versionchange` handler, so an older tab still blocks a newer tab's upgrade — the newer tab now reports it cleanly instead of hanging, but the upgrade cannot proceed until the old tab closes. Upstream issue: pingdotgg#5116 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CkwXzkvT38LpY5LTfareGs (cherry picked from commit c99c2bc)

coderabbitai · 2026-07-31T13:17:46Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 8ef354d7-47ac-47c0-9bac-9b1b12a185b8

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

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

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

macroscopeapp · 2026-07-31T13:24:37Z

Approvability

Verdict: Approved 7fbb4fc

Straightforward bug fix that handles IndexedDB's 'blocked' event - converts an indefinite hang into a clear error message with user guidance. Changes are self-contained, well-tested, and address a specific edge case without broader side effects.

^{You can customize Macroscope's approvability policy. Learn more.}

Review catch: `blocked` does not cancel the open request. When the blocking connection goes away the request still completes and fires `success`, but the `Effect.callback` has already failed, so the second `resume` is a no-op and the `IDBDatabase` never reaches `acquireRelease` to be closed. That leaked connection then holds the database open for the lifetime of the page and blocks every later version change — the same deadlock the `blocked` handler was added to break. Track whether the callback has settled and close the handle instead of leaking it. Aborting the request would be the tidier fix, but `IDBOpenDBRequest` inherits from `IDBRequest`, which has no `abort()`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CkwXzkvT38LpY5LTfareGs

Jardo-51 · 2026-08-01T10:49:19Z

Rescoping this based on further investigation — full detail in #5116.

Short version: the blocked handler is correct and worth having, but it does not fix the splash hang that motivated it, and two claims in my PR description don't hold.

The reachability argument.blocked fires only when an open needs a version change and another connection is open. DATABASE_VERSION has been 4 since #3795 (2026-07-09), so any client built since then performs same-version opens, which never open a version-change transaction and therefore can never emit blocked. The path was unreachable in my environment.

Corrections to the description above:

"It reproduces with several app tabs open in one browser profile" — I never ran that. I only ever had a single tab open during the investigation. Those steps were reasoned from the spec, not executed.
"Verified against a live wedged browser profile: the tab now reports the error instead of hanging" — this doesn't hold either. The hang reproduced again with this patch applied, single tab. The one clean boot I saw was coincidence, matching the "deleting IndexedDB bought exactly one clean boot" note already in the description.

What the patch is still good for. A blocked event with no listener genuinely never settles — that's a real hole regardless of how it's reached. It matters for anyone upgrading a database created before #3795 (v2 → v4), and for the next DATABASE_VERSION bump. The versionchange follow-up noted under Scope is the more broadly useful one.

So: suggest dropping the Fixes #5116 link and taking this as defensive hardening on its own merits. The actual splash hang looks like the unbounded auth bootstrap behind the root route's async beforeLoad — no timeout on fetchSessionState, and no defaultPendingComponent, so any stall there leaves the static #boot-shell markup on screen with no error, retry, or log. Trace is in #5116.

Let me know whether you'd prefer I retitle this one and open a separate issue for the auth gate, or close it in favour of a combined fix.

t3dotgg · 2026-08-28T12:55:00Z

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

The author states that this IndexedDB blocked path was not observed and did not cause the splash-screen failure that prompted the PR. The remaining version-upgrade case is too theoretical to keep in the active backlog.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed.

Jardo-51 · 2026-07-31T13:17:31Z

What Changed

openDatabase in apps/web/src/connection/storage.ts now registers a blocked listener on the indexedDB.open request, resuming with the same ConnectionTransientError the existing error path uses. A second commit closes the database handle if the request later succeeds after having reported blocked.

Two files, 35 lines including the test.

Why

IDBOpenDBRequest fires blocked — instead ofsuccess or error — when another connection holds the database open and the open request needs a version change. openDatabase registered only upgradeneeded, error, and success, so in that case resume is never called and the Effect.callback never settles. There is no timeout on it, so it hangs for the lifetime of the page.

Scope of the claim, up front: this is spec-driven hardening for a path I have not observed in the wild. I originally opened this believing it explained a splash-screen hang I was chasing. It did not — that turned out to be a corrupted browser HTTP disk cache, written up in #5116. The first version of this description claimed a multi-tab reproduction and a live verification against a wedged profile; I performed neither. Both are removed. The full correction is in the comment thread below and in #5116.

What remains is a real hole regardless of how often it is reached. The realistic trigger is a DATABASE_VERSION bump: every existing user's next open becomes an upgrade open, and any user with a second tab still holding a connection at that moment gets blocked and hangs — no error, no retry, no log. That version has already been bumped twice (v2, then v4 in #3795), so this is a predictable consequence of each schema change rather than an exotic race.

The second commit fixes a related leak found in review: blocked does not cancel the request, so a later success handed back an IDBDatabase that nothing owned or closed — a connection held for the lifetime of the page, blocking every future version change. The callback now tracks whether it settled and closes the late handle.

Scope

Deliberately narrow. The connection is held for the lifetime of the page via Effect.acquireRelease with no versionchange handler, so an older tab still blocks a newer tab's upgrade — the newer tab now reports it cleanly rather than hanging, but the upgrade cannot proceed until the old tab closes. Fixing that means adding versionchange → database.close(), which first needs the read/write helpers hardened, since database.transaction() throws synchronously on a closed handle and would surface as a defect rather than a typed failure. Happy to do it as a follow-up; kept out of here to keep the change small.

Testing

New test dispatches blocked at a stubbed indexedDB.open and asserts the effect fails. openDatabase is exported for it, matching how makeCatalogStore / makeCatalogBackend are already exposed to the same test file.
The test is not vacuous: with the blocked handler removed it hangs and times out at 60s, reproducing the non-settling request in the harness. With the handler it passes.
The second commit's late-success guard has its own test; removing the guard fails it.
vp test run --project unit src/connection/storage.test.ts → 5 passed.
tsgo --noEmit on apps/web → exit 0. vp lint on both files → clean.

Not verified in a browser — see the scope note above.

Checklist

This PR is small and focused
I explained what changed and why
I included before/after screenshots for any UI changes — no visual change; the only user-visible difference is that an existing error state is reached instead of an indefinite hang
I included a video for animation/interaction changes — n/a

…"blocked" `openDatabase` registered only `upgradeneeded`, `error`, and `success` on the `indexedDB.open` request. `blocked` fires *instead of* `success`/`error` when another connection holds the database open and the open needs a version change, so the `Effect.callback` never resumed and the web client hung forever on the splash screen — no error, no timeout, no retry, and no network activity or CPU use to diagnose it from. The hung tab never released its own connection either, so every subsequent load blocked as well. Resume with the existing transient error instead, so the failure surfaces in the UI and can be retried. Covered by a test that dispatches `blocked`; without the handler that test times out rather than failing. This does not address the related gap that the connection is held for the lifetime of the page with no `versionchange` handler, so an older tab still blocks a newer tab's upgrade — the newer tab now reports it cleanly instead of hanging, but the upgrade cannot proceed until the old tab closes. Upstream issue: pingdotgg#5116 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CkwXzkvT38LpY5LTfareGs (cherry picked from commit c99c2bc)

coderabbitai · 2026-07-31T13:17:46Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 8ef354d7-47ac-47c0-9bac-9b1b12a185b8

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

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

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

macroscopeapp · 2026-07-31T13:24:37Z

Approvability

Verdict: Approved 7fbb4fc

Straightforward bug fix that handles IndexedDB's 'blocked' event - converts an indefinite hang into a clear error message with user guidance. Changes are self-contained, well-tested, and address a specific edge case without broader side effects.

^{You can customize Macroscope's approvability policy. Learn more.}

Review catch: `blocked` does not cancel the open request. When the blocking connection goes away the request still completes and fires `success`, but the `Effect.callback` has already failed, so the second `resume` is a no-op and the `IDBDatabase` never reaches `acquireRelease` to be closed. That leaked connection then holds the database open for the lifetime of the page and blocks every later version change — the same deadlock the `blocked` handler was added to break. Track whether the callback has settled and close the handle instead of leaking it. Aborting the request would be the tidier fix, but `IDBOpenDBRequest` inherits from `IDBRequest`, which has no `abort()`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CkwXzkvT38LpY5LTfareGs

Jardo-51 · 2026-08-01T10:49:19Z

Rescoping this based on further investigation — full detail in #5116.

Short version: the blocked handler is correct and worth having, but it does not fix the splash hang that motivated it, and two claims in my PR description don't hold.

The reachability argument.blocked fires only when an open needs a version change and another connection is open. DATABASE_VERSION has been 4 since #3795 (2026-07-09), so any client built since then performs same-version opens, which never open a version-change transaction and therefore can never emit blocked. The path was unreachable in my environment.

Corrections to the description above:

"It reproduces with several app tabs open in one browser profile" — I never ran that. I only ever had a single tab open during the investigation. Those steps were reasoned from the spec, not executed.
"Verified against a live wedged browser profile: the tab now reports the error instead of hanging" — this doesn't hold either. The hang reproduced again with this patch applied, single tab. The one clean boot I saw was coincidence, matching the "deleting IndexedDB bought exactly one clean boot" note already in the description.

What the patch is still good for. A blocked event with no listener genuinely never settles — that's a real hole regardless of how it's reached. It matters for anyone upgrading a database created before #3795 (v2 → v4), and for the next DATABASE_VERSION bump. The versionchange follow-up noted under Scope is the more broadly useful one.

So: suggest dropping the Fixes #5116 link and taking this as defensive hardening on its own merits. The actual splash hang looks like the unbounded auth bootstrap behind the root route's async beforeLoad — no timeout on fetchSessionState, and no defaultPendingComponent, so any stall there leaves the static #boot-shell markup on screen with no error, retry, or log. Trace is in #5116.

Let me know whether you'd prefer I retitle this one and open a separate issue for the auth gate, or close it in favour of a combined fix.

t3dotgg · 2026-08-28T12:55:00Z

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

The author states that this IndexedDB blocked path was not observed and did not cause the splash-screen failure that prompted the PR. The remaining version-upgrade case is too theoretical to keep in the active backlog.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed.

Jardo-51 · 2026-07-31T13:17:31Z

What Changed

openDatabase in apps/web/src/connection/storage.ts now registers a blocked listener on the indexedDB.open request, resuming with the same ConnectionTransientError the existing error path uses. A second commit closes the database handle if the request later succeeds after having reported blocked.

Two files, 35 lines including the test.

Why

IDBOpenDBRequest fires blocked — instead ofsuccess or error — when another connection holds the database open and the open request needs a version change. openDatabase registered only upgradeneeded, error, and success, so in that case resume is never called and the Effect.callback never settles. There is no timeout on it, so it hangs for the lifetime of the page.

Scope of the claim, up front: this is spec-driven hardening for a path I have not observed in the wild. I originally opened this believing it explained a splash-screen hang I was chasing. It did not — that turned out to be a corrupted browser HTTP disk cache, written up in #5116. The first version of this description claimed a multi-tab reproduction and a live verification against a wedged profile; I performed neither. Both are removed. The full correction is in the comment thread below and in #5116.

What remains is a real hole regardless of how often it is reached. The realistic trigger is a DATABASE_VERSION bump: every existing user's next open becomes an upgrade open, and any user with a second tab still holding a connection at that moment gets blocked and hangs — no error, no retry, no log. That version has already been bumped twice (v2, then v4 in #3795), so this is a predictable consequence of each schema change rather than an exotic race.

The second commit fixes a related leak found in review: blocked does not cancel the request, so a later success handed back an IDBDatabase that nothing owned or closed — a connection held for the lifetime of the page, blocking every future version change. The callback now tracks whether it settled and closes the late handle.

Scope

Deliberately narrow. The connection is held for the lifetime of the page via Effect.acquireRelease with no versionchange handler, so an older tab still blocks a newer tab's upgrade — the newer tab now reports it cleanly rather than hanging, but the upgrade cannot proceed until the old tab closes. Fixing that means adding versionchange → database.close(), which first needs the read/write helpers hardened, since database.transaction() throws synchronously on a closed handle and would surface as a defect rather than a typed failure. Happy to do it as a follow-up; kept out of here to keep the change small.

Testing

New test dispatches blocked at a stubbed indexedDB.open and asserts the effect fails. openDatabase is exported for it, matching how makeCatalogStore / makeCatalogBackend are already exposed to the same test file.
The test is not vacuous: with the blocked handler removed it hangs and times out at 60s, reproducing the non-settling request in the harness. With the handler it passes.
The second commit's late-success guard has its own test; removing the guard fails it.
vp test run --project unit src/connection/storage.test.ts → 5 passed.
tsgo --noEmit on apps/web → exit 0. vp lint on both files → clean.

Not verified in a browser — see the scope note above.

Checklist

This PR is small and focused
I explained what changed and why
I included before/after screenshots for any UI changes — no visual change; the only user-visible difference is that an existing error state is reached instead of an indefinite hang
I included a video for animation/interaction changes — n/a

…"blocked" `openDatabase` registered only `upgradeneeded`, `error`, and `success` on the `indexedDB.open` request. `blocked` fires *instead of* `success`/`error` when another connection holds the database open and the open needs a version change, so the `Effect.callback` never resumed and the web client hung forever on the splash screen — no error, no timeout, no retry, and no network activity or CPU use to diagnose it from. The hung tab never released its own connection either, so every subsequent load blocked as well. Resume with the existing transient error instead, so the failure surfaces in the UI and can be retried. Covered by a test that dispatches `blocked`; without the handler that test times out rather than failing. This does not address the related gap that the connection is held for the lifetime of the page with no `versionchange` handler, so an older tab still blocks a newer tab's upgrade — the newer tab now reports it cleanly instead of hanging, but the upgrade cannot proceed until the old tab closes. Upstream issue: pingdotgg#5116 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CkwXzkvT38LpY5LTfareGs (cherry picked from commit c99c2bc)

coderabbitai · 2026-07-31T13:17:46Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 8ef354d7-47ac-47c0-9bac-9b1b12a185b8

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

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

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

macroscopeapp · 2026-07-31T13:24:37Z

Approvability

Verdict: Approved 7fbb4fc

Straightforward bug fix that handles IndexedDB's 'blocked' event - converts an indefinite hang into a clear error message with user guidance. Changes are self-contained, well-tested, and address a specific edge case without broader side effects.

^{You can customize Macroscope's approvability policy. Learn more.}

Review catch: `blocked` does not cancel the open request. When the blocking connection goes away the request still completes and fires `success`, but the `Effect.callback` has already failed, so the second `resume` is a no-op and the `IDBDatabase` never reaches `acquireRelease` to be closed. That leaked connection then holds the database open for the lifetime of the page and blocks every later version change — the same deadlock the `blocked` handler was added to break. Track whether the callback has settled and close the handle instead of leaking it. Aborting the request would be the tidier fix, but `IDBOpenDBRequest` inherits from `IDBRequest`, which has no `abort()`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CkwXzkvT38LpY5LTfareGs

Jardo-51 · 2026-08-01T10:49:19Z

Rescoping this based on further investigation — full detail in #5116.

Short version: the blocked handler is correct and worth having, but it does not fix the splash hang that motivated it, and two claims in my PR description don't hold.

The reachability argument.blocked fires only when an open needs a version change and another connection is open. DATABASE_VERSION has been 4 since #3795 (2026-07-09), so any client built since then performs same-version opens, which never open a version-change transaction and therefore can never emit blocked. The path was unreachable in my environment.

Corrections to the description above:

"It reproduces with several app tabs open in one browser profile" — I never ran that. I only ever had a single tab open during the investigation. Those steps were reasoned from the spec, not executed.
"Verified against a live wedged browser profile: the tab now reports the error instead of hanging" — this doesn't hold either. The hang reproduced again with this patch applied, single tab. The one clean boot I saw was coincidence, matching the "deleting IndexedDB bought exactly one clean boot" note already in the description.

What the patch is still good for. A blocked event with no listener genuinely never settles — that's a real hole regardless of how it's reached. It matters for anyone upgrading a database created before #3795 (v2 → v4), and for the next DATABASE_VERSION bump. The versionchange follow-up noted under Scope is the more broadly useful one.

So: suggest dropping the Fixes #5116 link and taking this as defensive hardening on its own merits. The actual splash hang looks like the unbounded auth bootstrap behind the root route's async beforeLoad — no timeout on fetchSessionState, and no defaultPendingComponent, so any stall there leaves the static #boot-shell markup on screen with no error, retry, or log. Trace is in #5116.

Let me know whether you'd prefer I retitle this one and open a separate issue for the auth gate, or close it in favour of a combined fix.

t3dotgg · 2026-08-28T12:55:00Z

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

The author states that this IndexedDB blocked path was not observed and did not cause the splash-screen failure that prompted the PR. The remaining version-upgrade case is too theoretical to keep in the active backlog.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed.

Jardo-51 · 2026-07-31T13:17:31Z

What Changed

openDatabase in apps/web/src/connection/storage.ts now registers a blocked listener on the indexedDB.open request, resuming with the same ConnectionTransientError the existing error path uses. A second commit closes the database handle if the request later succeeds after having reported blocked.

Two files, 35 lines including the test.

Why

IDBOpenDBRequest fires blocked — instead ofsuccess or error — when another connection holds the database open and the open request needs a version change. openDatabase registered only upgradeneeded, error, and success, so in that case resume is never called and the Effect.callback never settles. There is no timeout on it, so it hangs for the lifetime of the page.

Scope of the claim, up front: this is spec-driven hardening for a path I have not observed in the wild. I originally opened this believing it explained a splash-screen hang I was chasing. It did not — that turned out to be a corrupted browser HTTP disk cache, written up in #5116. The first version of this description claimed a multi-tab reproduction and a live verification against a wedged profile; I performed neither. Both are removed. The full correction is in the comment thread below and in #5116.

What remains is a real hole regardless of how often it is reached. The realistic trigger is a DATABASE_VERSION bump: every existing user's next open becomes an upgrade open, and any user with a second tab still holding a connection at that moment gets blocked and hangs — no error, no retry, no log. That version has already been bumped twice (v2, then v4 in #3795), so this is a predictable consequence of each schema change rather than an exotic race.

The second commit fixes a related leak found in review: blocked does not cancel the request, so a later success handed back an IDBDatabase that nothing owned or closed — a connection held for the lifetime of the page, blocking every future version change. The callback now tracks whether it settled and closes the late handle.

Scope

Deliberately narrow. The connection is held for the lifetime of the page via Effect.acquireRelease with no versionchange handler, so an older tab still blocks a newer tab's upgrade — the newer tab now reports it cleanly rather than hanging, but the upgrade cannot proceed until the old tab closes. Fixing that means adding versionchange → database.close(), which first needs the read/write helpers hardened, since database.transaction() throws synchronously on a closed handle and would surface as a defect rather than a typed failure. Happy to do it as a follow-up; kept out of here to keep the change small.

Testing

New test dispatches blocked at a stubbed indexedDB.open and asserts the effect fails. openDatabase is exported for it, matching how makeCatalogStore / makeCatalogBackend are already exposed to the same test file.
The test is not vacuous: with the blocked handler removed it hangs and times out at 60s, reproducing the non-settling request in the harness. With the handler it passes.
The second commit's late-success guard has its own test; removing the guard fails it.
vp test run --project unit src/connection/storage.test.ts → 5 passed.
tsgo --noEmit on apps/web → exit 0. vp lint on both files → clean.

Not verified in a browser — see the scope note above.

Checklist

This PR is small and focused
I explained what changed and why
I included before/after screenshots for any UI changes — no visual change; the only user-visible difference is that an existing error state is reached instead of an indefinite hang
I included a video for animation/interaction changes — n/a

…"blocked" `openDatabase` registered only `upgradeneeded`, `error`, and `success` on the `indexedDB.open` request. `blocked` fires *instead of* `success`/`error` when another connection holds the database open and the open needs a version change, so the `Effect.callback` never resumed and the web client hung forever on the splash screen — no error, no timeout, no retry, and no network activity or CPU use to diagnose it from. The hung tab never released its own connection either, so every subsequent load blocked as well. Resume with the existing transient error instead, so the failure surfaces in the UI and can be retried. Covered by a test that dispatches `blocked`; without the handler that test times out rather than failing. This does not address the related gap that the connection is held for the lifetime of the page with no `versionchange` handler, so an older tab still blocks a newer tab's upgrade — the newer tab now reports it cleanly instead of hanging, but the upgrade cannot proceed until the old tab closes. Upstream issue: pingdotgg#5116 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CkwXzkvT38LpY5LTfareGs (cherry picked from commit c99c2bc)

coderabbitai · 2026-07-31T13:17:46Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 8ef354d7-47ac-47c0-9bac-9b1b12a185b8

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

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

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

macroscopeapp · 2026-07-31T13:24:37Z

Approvability

Verdict: Approved 7fbb4fc

Straightforward bug fix that handles IndexedDB's 'blocked' event - converts an indefinite hang into a clear error message with user guidance. Changes are self-contained, well-tested, and address a specific edge case without broader side effects.

^{You can customize Macroscope's approvability policy. Learn more.}

Review catch: `blocked` does not cancel the open request. When the blocking connection goes away the request still completes and fires `success`, but the `Effect.callback` has already failed, so the second `resume` is a no-op and the `IDBDatabase` never reaches `acquireRelease` to be closed. That leaked connection then holds the database open for the lifetime of the page and blocks every later version change — the same deadlock the `blocked` handler was added to break. Track whether the callback has settled and close the handle instead of leaking it. Aborting the request would be the tidier fix, but `IDBOpenDBRequest` inherits from `IDBRequest`, which has no `abort()`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CkwXzkvT38LpY5LTfareGs

Jardo-51 · 2026-08-01T10:49:19Z

Rescoping this based on further investigation — full detail in #5116.

Short version: the blocked handler is correct and worth having, but it does not fix the splash hang that motivated it, and two claims in my PR description don't hold.

The reachability argument.blocked fires only when an open needs a version change and another connection is open. DATABASE_VERSION has been 4 since #3795 (2026-07-09), so any client built since then performs same-version opens, which never open a version-change transaction and therefore can never emit blocked. The path was unreachable in my environment.

Corrections to the description above:

"It reproduces with several app tabs open in one browser profile" — I never ran that. I only ever had a single tab open during the investigation. Those steps were reasoned from the spec, not executed.
"Verified against a live wedged browser profile: the tab now reports the error instead of hanging" — this doesn't hold either. The hang reproduced again with this patch applied, single tab. The one clean boot I saw was coincidence, matching the "deleting IndexedDB bought exactly one clean boot" note already in the description.

What the patch is still good for. A blocked event with no listener genuinely never settles — that's a real hole regardless of how it's reached. It matters for anyone upgrading a database created before #3795 (v2 → v4), and for the next DATABASE_VERSION bump. The versionchange follow-up noted under Scope is the more broadly useful one.

So: suggest dropping the Fixes #5116 link and taking this as defensive hardening on its own merits. The actual splash hang looks like the unbounded auth bootstrap behind the root route's async beforeLoad — no timeout on fetchSessionState, and no defaultPendingComponent, so any stall there leaves the static #boot-shell markup on screen with no error, retry, or log. Trace is in #5116.

Let me know whether you'd prefer I retitle this one and open a separate issue for the auth gate, or close it in favour of a combined fix.

t3dotgg · 2026-08-28T12:55:00Z

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

The author states that this IndexedDB blocked path was not observed and did not cause the splash-screen failure that prompted the PR. The remaining version-upgrade case is too theoretical to keep in the active backlog.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed.

github-actionsBot added vouch:unvouched PR author is not yet trusted in the VOUCHED list. size:S 10-29 changed lines (additions + deletions). labels Jul 31, 2026

macroscopeappBot reviewed Jul 31, 2026
View reviewed changes

Comment threadapps/web/src/connection/storage.ts

github-actionsBot added size:M 30-99 changed lines (additions + deletions). and removed size:S 10-29 changed lines (additions + deletions). labels Jul 31, 2026

macroscopeappBot approved these changes Jul 31, 2026
View reviewed changes

Jardo-51 mentioned this pull request Aug 1, 2026
[Bug]: Web client hangs forever on splash — indexedDB.open has no "blocked" handler, so the boot effect never settles #5116
Closed
2 tasks

Jardo-51 mentioned this pull request Aug 1, 2026
fix(web): settle the connection database open when IndexedDB reports "blocked" Jardo-51/t3code#3
Draft

t3dotgg closed this Aug 28, 2026

github-actionsBot added vouch:unvouched PR author is not yet trusted in the VOUCHED list. size:S 10-29 changed lines (additions + deletions). labels Jul 31, 2026

macroscopeappBot reviewed Jul 31, 2026
View reviewed changes

Comment threadapps/web/src/connection/storage.ts

github-actionsBot added size:M 30-99 changed lines (additions + deletions). and removed size:S 10-29 changed lines (additions + deletions). labels Jul 31, 2026

macroscopeappBot approved these changes Jul 31, 2026
View reviewed changes

Jardo-51 mentioned this pull request Aug 1, 2026
[Bug]: Web client hangs forever on splash — indexedDB.open has no "blocked" handler, so the boot effect never settles #5116
Closed
2 tasks

Jardo-51 mentioned this pull request Aug 1, 2026
fix(web): settle the connection database open when IndexedDB reports "blocked" Jardo-51/t3code#3
Draft

t3dotgg closed this Aug 28, 2026

github-actionsBot added vouch:unvouched PR author is not yet trusted in the VOUCHED list. size:S 10-29 changed lines (additions + deletions). labels Jul 31, 2026

macroscopeappBot reviewed Jul 31, 2026
View reviewed changes

Comment threadapps/web/src/connection/storage.ts

github-actionsBot added size:M 30-99 changed lines (additions + deletions). and removed size:S 10-29 changed lines (additions + deletions). labels Jul 31, 2026

macroscopeappBot approved these changes Jul 31, 2026
View reviewed changes

Jardo-51 mentioned this pull request Aug 1, 2026
[Bug]: Web client hangs forever on splash — indexedDB.open has no "blocked" handler, so the boot effect never settles #5116
Closed
2 tasks

Jardo-51 mentioned this pull request Aug 1, 2026
fix(web): settle the connection database open when IndexedDB reports "blocked" Jardo-51/t3code#3
Draft

t3dotgg closed this Aug 28, 2026

github-actionsBot added vouch:unvouched PR author is not yet trusted in the VOUCHED list. size:S 10-29 changed lines (additions + deletions). labels Jul 31, 2026

macroscopeappBot reviewed Jul 31, 2026
View reviewed changes

Comment threadapps/web/src/connection/storage.ts

github-actionsBot added size:M 30-99 changed lines (additions + deletions). and removed size:S 10-29 changed lines (additions + deletions). labels Jul 31, 2026

macroscopeappBot approved these changes Jul 31, 2026
View reviewed changes

Jardo-51 mentioned this pull request Aug 1, 2026
[Bug]: Web client hangs forever on splash — indexedDB.open has no "blocked" handler, so the boot effect never settles #5116
Closed
2 tasks

Jardo-51 mentioned this pull request Aug 1, 2026
fix(web): settle the connection database open when IndexedDB reports "blocked" Jardo-51/t3code#3
Draft

t3dotgg closed this Aug 28, 2026

github-actionsBot added vouch:unvouched PR author is not yet trusted in the VOUCHED list. size:S 10-29 changed lines (additions + deletions). labels Jul 31, 2026

macroscopeappBot reviewed Jul 31, 2026
View reviewed changes

Comment threadapps/web/src/connection/storage.ts

github-actionsBot added size:M 30-99 changed lines (additions + deletions). and removed size:S 10-29 changed lines (additions + deletions). labels Jul 31, 2026

macroscopeappBot approved these changes Jul 31, 2026
View reviewed changes

Jardo-51 mentioned this pull request Aug 1, 2026
[Bug]: Web client hangs forever on splash — indexedDB.open has no "blocked" handler, so the boot effect never settles #5116
Closed
2 tasks

Jardo-51 mentioned this pull request Aug 1, 2026
fix(web): settle the connection database open when IndexedDB reports "blocked" Jardo-51/t3code#3
Draft

t3dotgg closed this Aug 28, 2026

github-actionsBot added vouch:unvouched PR author is not yet trusted in the VOUCHED list. size:S 10-29 changed lines (additions + deletions). labels Jul 31, 2026

macroscopeappBot reviewed Jul 31, 2026
View reviewed changes

Comment threadapps/web/src/connection/storage.ts

github-actionsBot added size:M 30-99 changed lines (additions + deletions). and removed size:S 10-29 changed lines (additions + deletions). labels Jul 31, 2026

macroscopeappBot approved these changes Jul 31, 2026
View reviewed changes

Jardo-51 mentioned this pull request Aug 1, 2026
[Bug]: Web client hangs forever on splash — indexedDB.open has no "blocked" handler, so the boot effect never settles #5116
Closed
2 tasks

Jardo-51 mentioned this pull request Aug 1, 2026
fix(web): settle the connection database open when IndexedDB reports "blocked" Jardo-51/t3code#3
Draft

t3dotgg closed this Aug 28, 2026

github-actionsBot added vouch:unvouched PR author is not yet trusted in the VOUCHED list. size:S 10-29 changed lines (additions + deletions). labels Jul 31, 2026

macroscopeappBot reviewed Jul 31, 2026
View reviewed changes

Comment threadapps/web/src/connection/storage.ts

github-actionsBot added size:M 30-99 changed lines (additions + deletions). and removed size:S 10-29 changed lines (additions + deletions). labels Jul 31, 2026

macroscopeappBot approved these changes Jul 31, 2026
View reviewed changes

Jardo-51 mentioned this pull request Aug 1, 2026
[Bug]: Web client hangs forever on splash — indexedDB.open has no "blocked" handler, so the boot effect never settles #5116
Closed
2 tasks

Jardo-51 mentioned this pull request Aug 1, 2026
fix(web): settle the connection database open when IndexedDB reports "blocked" Jardo-51/t3code#3
Draft

t3dotgg closed this Aug 28, 2026

github-actionsBot added vouch:unvouched PR author is not yet trusted in the VOUCHED list. size:S 10-29 changed lines (additions + deletions). labels Jul 31, 2026

macroscopeappBot reviewed Jul 31, 2026
View reviewed changes

Comment threadapps/web/src/connection/storage.ts

github-actionsBot added size:M 30-99 changed lines (additions + deletions). and removed size:S 10-29 changed lines (additions + deletions). labels Jul 31, 2026

macroscopeappBot approved these changes Jul 31, 2026
View reviewed changes

Jardo-51 mentioned this pull request Aug 1, 2026
[Bug]: Web client hangs forever on splash — indexedDB.open has no "blocked" handler, so the boot effect never settles #5116
Closed
2 tasks

Jardo-51 mentioned this pull request Aug 1, 2026
fix(web): settle the connection database open when IndexedDB reports "blocked" Jardo-51/t3code#3
Draft

t3dotgg closed this Aug 28, 2026

Uh oh!

Conversation

Jardo-51 commented Jul 31, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What Changed

Why

Scope

Testing

Checklist

Uh oh!

coderabbitaiBot commented Jul 31, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Review skipped

Uh oh!

Uh oh!

macroscopeappBot commented Jul 31, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Approvability

Uh oh!

Jardo-51 commented Aug 1, 2026

Uh oh!

t3dotgg commented Aug 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

Jardo-51 commented Jul 31, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What Changed

Why

Scope

Testing

Checklist

Uh oh!

coderabbitaiBot commented Jul 31, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Review skipped

Uh oh!

Uh oh!

macroscopeappBot commented Jul 31, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Approvability

Uh oh!

Jardo-51 commented Aug 1, 2026

Uh oh!

t3dotgg commented Aug 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

Jardo-51 commented Jul 31, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What Changed

Why

Scope

Testing

Checklist

Uh oh!

coderabbitaiBot commented Jul 31, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Review skipped

Uh oh!

Uh oh!

macroscopeappBot commented Jul 31, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Approvability

Jardo-51 commented Jul 31, 2026•
edited
Loading

coderabbitaiBot commented Jul 31, 2026•
edited
Loading

macroscopeappBot commented Jul 31, 2026•
edited
Loading

Jardo-51 commented Jul 31, 2026•
edited
Loading

coderabbitaiBot commented Jul 31, 2026•
edited
Loading

macroscopeappBot commented Jul 31, 2026•
edited
Loading

Jardo-51 commented Jul 31, 2026•
edited
Loading

coderabbitaiBot commented Jul 31, 2026•
edited
Loading

macroscopeappBot commented Jul 31, 2026•
edited
Loading

Jardo-51 commented Jul 31, 2026•
edited
Loading

coderabbitaiBot commented Jul 31, 2026•
edited
Loading

macroscopeappBot commented Jul 31, 2026•
edited
Loading

Jardo-51 commented Jul 31, 2026•
edited
Loading