fix(t3x): the Windows transient-crash retry could never fire; classify on the code vp prints (#47) - #79

Merged
radroid merged 1 commit into
mainfrom
t3x/win-exit-diagnostics
Aug 12, 2026
Merged

fix(t3x): the Windows transient-crash retry could never fire; classify on the code vp prints (#47)#79
radroid merged 1 commit into
mainfrom
t3x/win-exit-diagnostics

Conversation

@radroid

@radroidradroid commented Aug 11, 2026

Copy link
Copy Markdown
Owner

Refs #47. This started as the issue's "translate these numeric exit codes into a readable diagnostic" item and turned up a live bug on the way.

The retry has been dead code since it was written

t3x-release.yml serialises the Windows desktop build and retries it three times when the failure looks like a Windows process-startup condition. The classifier was:

grep -qiE '0xC0000142|0xC0000005|STATUS_DLL_INIT_FAILED|Access violation'"$log"

The failure it was written for contains none of those. Verbatim from the issue:

[3] @t3tools/desktop#build: node scripts/build-preview-annotation-css.mjs FAILED (exit code: -1073741502)

-1073741502is0xC0000142 — as a signed 32-bit integer, which is how Node reports a child's status and therefore the only form that reaches the log. The hex spelling never appears anywhere.

So every attempt fell through to the not a known transient branch and exited. Checked rather than assumed — the old pattern run against the issue's log:

old grep against the observed log:
NO MATCH -> the retry could never have fired

The next occurrence would have cost the release the retry was added to protect.

What replaces it

scripts/t3x/windows-exit-codes.mjs matches all four spellings a status appears in (signed decimal, unsigned decimal, hex, NTSTATUS name) and also does the issue's other ask — it says what the status means, so a recurrence is diagnosed from the log instead of from a bare negative integer:

STATUS_DLL_INIT_FAILED (0xC0000142, reported by Node as -1073741502)
What it means: A DLL's initialisation routine failed while the process was starting, so the program never reached main().
Retryable: Usually desktop-heap or session resource pressure from spawning several processes at once. Retry, and prefer serialising the build over widening the pool.

It also distinguishes retryable from not, which a flat grep could not:

StatusRetry?
STATUS_DLL_INIT_FAILED · STATUS_ACCESS_VIOLATIONyes — both show up under concurrent-spawn pressure
STATUS_HEAP_CORRUPTION · STATUS_STACK_BUFFER_OVERRUNno — real bugs
STATUS_DLL_NOT_FOUND · STATUS_INVALID_IMAGE_FORMATno — deterministic, retrying cannot help

A log carrying more than one status is transient only if all of them are, so a heap corruption alongside a DLL-init failure stops the build rather than hiding behind another two minutes of compute.

The exit code is the interface — 0 retry, 1 stop — so the workflow keeps if node … --classify "$log"; then and parses nothing.

Two details the tests pin down

Both bit while writing this:

  • \b is wrong at both ends of the signed form. The leading - is a non-word character, so \b-1073741502 never matches after code: ; and a trailing \b still matches inside -10737415021. The explicit lookarounds are what stop a build id being read as a crash — there is a test for exactly that.
  • The fixture is the issue's log, not a log shape invented here. If the real output had been paraphrased into the test, the test would have passed against the broken grep too.

15 tests. tsgo --noEmit on scripts exits 0 (types come from a hand-written .d.mts, same as render-release-notes); vp test run on scripts is 216 passed; vp lint clean; workflow YAML parses. The classifier CLI was exercised against three log shapes — transient, real-bug, and ordinary-failure — and exits 0/1/1 as intended.

Scope, and one thing I did not do

This is the diagnostic half only. The build-failure and artifact-freshness contracts the issue's Test case needed section also asks for both live in scripts/build-desktop-artifact.ts — which is upstream-owned, is not one of the ledger's rows, and which SEAMS.md:46 records the fork deliberately avoiding for this very issue: serialisation was done with vp run --concurrency-limit 1 in the workflow "rather than editing build-desktop-artifact.ts".

The triage comment assumed the diagnostic was "a small, self-contained, platform-specific improvement with no seam cost". That holds for what is here, because the workflow is fork-owned — but it does not hold for those two contracts. Spending a ledger row on the board's lowest-priority item is your call, so I left them open rather than making it.

🤖 Generated with Claude Code

@radroid@claude
fix(t3x): the Windows transient-crash retry could never fire; classif…
abbbfcd
…y on the code vp prints (#47)
The release workflow serialises the Windows desktop build and retries it three
times when the failure looks like a Windows process-startup condition. The
classifier was:
grep -qiE '0xC0000142|0xC0000005|STATUS_DLL_INIT_FAILED|Access violation'
and the failure it was written for contains none of those. What vp actually
prints, verbatim from #47, is:
[3] @t3tools/desktop#build: node …/build-preview-annotation-css.mjs FAILED (exit code: -1073741502)
`-1073741502` is `0xC0000142` as a signed 32-bit integer, which is the form Node
reports a child's status in and therefore the only form that reaches the log. The
hex spelling never appears. So every attempt would have fallen through to the
`not a known transient` branch and exited — the retry has been dead code since it
was written, and the next occurrence would have cost the release it was added to
protect. Confirmed by running the old pattern against the issue's log: no match.
`scripts/t3x/windows-exit-codes.mjs` replaces it, matching all four spellings a
status can appear in (signed decimal, unsigned decimal, hex, NTSTATUS name), and
also does the other half of #47 — it says what the status means.
The table distinguishes retryable from not, which the grep could not:
STATUS_DLL_INIT_FAILED and STATUS_ACCESS_VIOLATION are worth another attempt
under concurrent-spawn pressure; STATUS_HEAP_CORRUPTION,
STATUS_STACK_BUFFER_OVERRUN, STATUS_DLL_NOT_FOUND and STATUS_INVALID_IMAGE_FORMAT
are not, and retrying those three times only makes a real failure slower to
diagnose. A log carrying more than one status is transient only if all of them
are, so a heap corruption alongside a DLL-init failure stops the build rather
than hiding behind another attempt.
Two details the tests pin down, both of which bit while writing this:
- `\b` is wrong at both ends of the signed form. The leading `-` is a non-word
character, so `\b-1073741502` never matches after `code: `; and a trailing
`\b` still matches inside `-10737415021`. The lookarounds are what stop a
build id being read as a crash.
- The classifier's exit code is the interface — 0 means retry, 1 means stop — so
the workflow keeps `if node … --classify "$log"; then` and parses nothing.
15 tests, built on the log pasted into the issue rather than on a log shape
invented here.
## Scope
This is the diagnostic half of #47. The build-failure and artifact-freshness
contracts its "Test case needed" section also asks for both live in
`scripts/build-desktop-artifact.ts`, which is upstream-owned, is not one of the
seam ledger's rows, and which SEAMS.md:46 records the fork deliberately avoiding
for this very issue — serialisation was done in the workflow "rather than editing
build-desktop-artifact.ts". Spending a ledger row on the board's lowest-priority
item is a call worth making deliberately, so those are left open.
Refs #47
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@coderabbitai

coderabbitaiBot commented Aug 11, 2026

Copy link
Copy Markdown

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: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 6f950052-f743-48a5-9236-41bfa7c16985

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.

@radroidradroid mentioned this pull request Aug 11, 2026
Merged
@radroid
radroid merged commit da5c939 into mainAug 12, 2026
2 checks passed
@radroid
radroid deleted the t3x/win-exit-diagnostics branch August 12, 2026 02:04
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@radroid
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
fix(t3x): the Windows transient-crash retry could never fire; classify on the code vp prints (#47) - #79
Merged
radroid merged 1 commit into
mainfrom 
t3x/win-exit-diagnostics
Aug 12, 2026
Merged
fix(t3x): the Windows transient-crash retry could never fire; classify on the code vp prints (#47)#79
radroid merged 1 commit into
mainfrom 
t3x/win-exit-diagnostics
Conversation
@radroid
@radroidradroid
commented
Aug 11, 2026

Copy link


Copy Markdown

Owner
Refs #47. This started as the issue's "translate these numeric exit codes into a readable diagnostic" item and turned up a live bug on the way.
The retry has been dead code since it was written
t3x-release.yml serialises the Windows desktop build and retries it three times when the failure looks like a Windows process-startup condition. The classifier was:
grep -qiE '0xC0000142|0xC0000005|STATUS_DLL_INIT_FAILED|Access violation'"$log"
The failure it was written for contains none of those. Verbatim from the issue:
[3] @t3tools/desktop#build: node scripts/build-preview-annotation-css.mjs FAILED (exit code: -1073741502)

-1073741502is0xC0000142 — as a signed 32-bit integer, which is how Node reports a child's status and therefore the only form that reaches the log. The hex spelling never appears anywhere.
So every attempt fell through to the not a known transient branch and exited. Checked rather than assumed — the old pattern run against the issue's log:
old grep against the observed log:
NO MATCH -> the retry could never have fired

The next occurrence would have cost the release the retry was added to protect.
What replaces it
scripts/t3x/windows-exit-codes.mjs matches all four spellings a status appears in (signed decimal, unsigned decimal, hex, NTSTATUS name) and also does the issue's other ask — it says what the status means, so a recurrence is diagnosed from the log instead of from a bare negative integer:
STATUS_DLL_INIT_FAILED (0xC0000142, reported by Node as -1073741502)
What it means: A DLL's initialisation routine failed while the process was starting, so the program never reached main().
Retryable: Usually desktop-heap or session resource pressure from spawning several processes at once. Retry, and prefer serialising the build over widening the pool.

It also distinguishes retryable from not, which a flat grep could not:
StatusRetry?
STATUS_DLL_INIT_FAILED · STATUS_ACCESS_VIOLATIONyes — both show up under concurrent-spawn pressure
STATUS_HEAP_CORRUPTION · STATUS_STACK_BUFFER_OVERRUNno — real bugs
STATUS_DLL_NOT_FOUND · STATUS_INVALID_IMAGE_FORMATno — deterministic, retrying cannot help
A log carrying more than one status is transient only if all of them are, so a heap corruption alongside a DLL-init failure stops the build rather than hiding behind another two minutes of compute.
The exit code is the interface — 0 retry, 1 stop — so the workflow keeps if node … --classify "$log"; then and parses nothing.
Two details the tests pin down
Both bit while writing this:
  • \b is wrong at both ends of the signed form. The leading - is a non-word character, so \b-1073741502 never matches after code: ; and a trailing \b still matches inside -10737415021. The explicit lookarounds are what stop a build id being read as a crash — there is a test for exactly that.
  • The fixture is the issue's log, not a log shape invented here. If the real output had been paraphrased into the test, the test would have passed against the broken grep too.
15 tests. tsgo --noEmit on scripts exits 0 (types come from a hand-written .d.mts, same as render-release-notes); vp test run on scripts is 216 passed; vp lint clean; workflow YAML parses. The classifier CLI was exercised against three log shapes — transient, real-bug, and ordinary-failure — and exits 0/1/1 as intended.
Scope, and one thing I did not do
This is the diagnostic half only. The build-failure and artifact-freshness contracts the issue's Test case needed section also asks for both live in scripts/build-desktop-artifact.ts — which is upstream-owned, is not one of the ledger's rows, and which SEAMS.md:46 records the fork deliberately avoiding for this very issue: serialisation was done with vp run --concurrency-limit 1 in the workflow "rather than editing build-desktop-artifact.ts".
The triage comment assumed the diagnostic was "a small, self-contained, platform-specific improvement with no seam cost". That holds for what is here, because the workflow is fork-owned — but it does not hold for those two contracts. Spending a ledger row on the board's lowest-priority item is your call, so I left them open rather than making it.
🤖 Generated with Claude Code
@radroid@claude
fix(t3x): the Windows transient-crash retry could never fire; classif…
abbbfcd
…y on the code vp prints (#47)
The release workflow serialises the Windows desktop build and retries it three
times when the failure looks like a Windows process-startup condition. The
classifier was:
grep -qiE '0xC0000142|0xC0000005|STATUS_DLL_INIT_FAILED|Access violation'
and the failure it was written for contains none of those. What vp actually
prints, verbatim from #47, is:
[3] @t3tools/desktop#build: node …/build-preview-annotation-css.mjs FAILED (exit code: -1073741502)
`-1073741502` is `0xC0000142` as a signed 32-bit integer, which is the form Node
reports a child's status in and therefore the only form that reaches the log. The
hex spelling never appears. So every attempt would have fallen through to the
`not a known transient` branch and exited — the retry has been dead code since it
was written, and the next occurrence would have cost the release it was added to
protect. Confirmed by running the old pattern against the issue's log: no match.
`scripts/t3x/windows-exit-codes.mjs` replaces it, matching all four spellings a
status can appear in (signed decimal, unsigned decimal, hex, NTSTATUS name), and
also does the other half of #47 — it says what the status means.
The table distinguishes retryable from not, which the grep could not:
STATUS_DLL_INIT_FAILED and STATUS_ACCESS_VIOLATION are worth another attempt
under concurrent-spawn pressure; STATUS_HEAP_CORRUPTION,
STATUS_STACK_BUFFER_OVERRUN, STATUS_DLL_NOT_FOUND and STATUS_INVALID_IMAGE_FORMAT
are not, and retrying those three times only makes a real failure slower to
diagnose. A log carrying more than one status is transient only if all of them
are, so a heap corruption alongside a DLL-init failure stops the build rather
than hiding behind another attempt.
Two details the tests pin down, both of which bit while writing this:
- `\b` is wrong at both ends of the signed form. The leading `-` is a non-word
character, so `\b-1073741502` never matches after `code: `; and a trailing
`\b` still matches inside `-10737415021`. The lookarounds are what stop a
build id being read as a crash.
- The classifier's exit code is the interface — 0 means retry, 1 means stop — so
the workflow keeps `if node … --classify "$log"; then` and parses nothing.
15 tests, built on the log pasted into the issue rather than on a log shape
invented here.
## Scope
This is the diagnostic half of #47. The build-failure and artifact-freshness
contracts its "Test case needed" section also asks for both live in
`scripts/build-desktop-artifact.ts`, which is upstream-owned, is not one of the
seam ledger's rows, and which SEAMS.md:46 records the fork deliberately avoiding
for this very issue — serialisation was done in the workflow "rather than editing
build-desktop-artifact.ts". Spending a ledger row on the board's lowest-priority
item is a call worth making deliberately, so those are left open.
Refs #47
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@coderabbitai
coderabbitaiBot
commented
Aug 11, 2026

Copy link


Copy Markdown

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: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 6f950052-f743-48a5-9236-41bfa7c16985
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.
@radroidradroid
mentioned this pull request
Aug 11, 2026
 Merged

@radroid
radroid
merged commit da5c939
into
mainAug 12, 2026

2 checks passed

@radroid
radroid
deleted the

t3x/win-exit-diagnostics

branch
August 12, 2026 02:04
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@radroid

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
fix(t3x): the Windows transient-crash retry could never fire; classify on the code vp prints (#47) - #79
Merged
radroid merged 1 commit into
mainfrom 
t3x/win-exit-diagnostics
Aug 12, 2026
Merged
fix(t3x): the Windows transient-crash retry could never fire; classify on the code vp prints (#47)#79
radroid merged 1 commit into
mainfrom 
t3x/win-exit-diagnostics
Conversation
@radroid
@radroidradroid
commented
Aug 11, 2026

Copy link


Copy Markdown

Owner
Refs #47. This started as the issue's "translate these numeric exit codes into a readable diagnostic" item and turned up a live bug on the way.
The retry has been dead code since it was written
t3x-release.yml serialises the Windows desktop build and retries it three times when the failure looks like a Windows process-startup condition. The classifier was:
grep -qiE '0xC0000142|0xC0000005|STATUS_DLL_INIT_FAILED|Access violation'"$log"
The failure it was written for contains none of those. Verbatim from the issue:
[3] @t3tools/desktop#build: node scripts/build-preview-annotation-css.mjs FAILED (exit code: -1073741502)

-1073741502is0xC0000142 — as a signed 32-bit integer, which is how Node reports a child's status and therefore the only form that reaches the log. The hex spelling never appears anywhere.
So every attempt fell through to the not a known transient branch and exited. Checked rather than assumed — the old pattern run against the issue's log:
old grep against the observed log:
NO MATCH -> the retry could never have fired

The next occurrence would have cost the release the retry was added to protect.
What replaces it
scripts/t3x/windows-exit-codes.mjs matches all four spellings a status appears in (signed decimal, unsigned decimal, hex, NTSTATUS name) and also does the issue's other ask — it says what the status means, so a recurrence is diagnosed from the log instead of from a bare negative integer:
STATUS_DLL_INIT_FAILED (0xC0000142, reported by Node as -1073741502)
What it means: A DLL's initialisation routine failed while the process was starting, so the program never reached main().
Retryable: Usually desktop-heap or session resource pressure from spawning several processes at once. Retry, and prefer serialising the build over widening the pool.

It also distinguishes retryable from not, which a flat grep could not:
StatusRetry?
STATUS_DLL_INIT_FAILED · STATUS_ACCESS_VIOLATIONyes — both show up under concurrent-spawn pressure
STATUS_HEAP_CORRUPTION · STATUS_STACK_BUFFER_OVERRUNno — real bugs
STATUS_DLL_NOT_FOUND · STATUS_INVALID_IMAGE_FORMATno — deterministic, retrying cannot help
A log carrying more than one status is transient only if all of them are, so a heap corruption alongside a DLL-init failure stops the build rather than hiding behind another two minutes of compute.
The exit code is the interface — 0 retry, 1 stop — so the workflow keeps if node … --classify "$log"; then and parses nothing.
Two details the tests pin down
Both bit while writing this:
  • \b is wrong at both ends of the signed form. The leading - is a non-word character, so \b-1073741502 never matches after code: ; and a trailing \b still matches inside -10737415021. The explicit lookarounds are what stop a build id being read as a crash — there is a test for exactly that.
  • The fixture is the issue's log, not a log shape invented here. If the real output had been paraphrased into the test, the test would have passed against the broken grep too.
15 tests. tsgo --noEmit on scripts exits 0 (types come from a hand-written .d.mts, same as render-release-notes); vp test run on scripts is 216 passed; vp lint clean; workflow YAML parses. The classifier CLI was exercised against three log shapes — transient, real-bug, and ordinary-failure — and exits 0/1/1 as intended.
Scope, and one thing I did not do
This is the diagnostic half only. The build-failure and artifact-freshness contracts the issue's Test case needed section also asks for both live in scripts/build-desktop-artifact.ts — which is upstream-owned, is not one of the ledger's rows, and which SEAMS.md:46 records the fork deliberately avoiding for this very issue: serialisation was done with vp run --concurrency-limit 1 in the workflow "rather than editing build-desktop-artifact.ts".
The triage comment assumed the diagnostic was "a small, self-contained, platform-specific improvement with no seam cost". That holds for what is here, because the workflow is fork-owned — but it does not hold for those two contracts. Spending a ledger row on the board's lowest-priority item is your call, so I left them open rather than making it.
🤖 Generated with Claude Code
@radroid@claude
fix(t3x): the Windows transient-crash retry could never fire; classif…
abbbfcd
…y on the code vp prints (#47)
The release workflow serialises the Windows desktop build and retries it three
times when the failure looks like a Windows process-startup condition. The
classifier was:
grep -qiE '0xC0000142|0xC0000005|STATUS_DLL_INIT_FAILED|Access violation'
and the failure it was written for contains none of those. What vp actually
prints, verbatim from #47, is:
[3] @t3tools/desktop#build: node …/build-preview-annotation-css.mjs FAILED (exit code: -1073741502)
`-1073741502` is `0xC0000142` as a signed 32-bit integer, which is the form Node
reports a child's status in and therefore the only form that reaches the log. The
hex spelling never appears. So every attempt would have fallen through to the
`not a known transient` branch and exited — the retry has been dead code since it
was written, and the next occurrence would have cost the release it was added to
protect. Confirmed by running the old pattern against the issue's log: no match.
`scripts/t3x/windows-exit-codes.mjs` replaces it, matching all four spellings a
status can appear in (signed decimal, unsigned decimal, hex, NTSTATUS name), and
also does the other half of #47 — it says what the status means.
The table distinguishes retryable from not, which the grep could not:
STATUS_DLL_INIT_FAILED and STATUS_ACCESS_VIOLATION are worth another attempt
under concurrent-spawn pressure; STATUS_HEAP_CORRUPTION,
STATUS_STACK_BUFFER_OVERRUN, STATUS_DLL_NOT_FOUND and STATUS_INVALID_IMAGE_FORMAT
are not, and retrying those three times only makes a real failure slower to
diagnose. A log carrying more than one status is transient only if all of them
are, so a heap corruption alongside a DLL-init failure stops the build rather
than hiding behind another attempt.
Two details the tests pin down, both of which bit while writing this:
- `\b` is wrong at both ends of the signed form. The leading `-` is a non-word
character, so `\b-1073741502` never matches after `code: `; and a trailing
`\b` still matches inside `-10737415021`. The lookarounds are what stop a
build id being read as a crash.
- The classifier's exit code is the interface — 0 means retry, 1 means stop — so
the workflow keeps `if node … --classify "$log"; then` and parses nothing.
15 tests, built on the log pasted into the issue rather than on a log shape
invented here.
## Scope
This is the diagnostic half of #47. The build-failure and artifact-freshness
contracts its "Test case needed" section also asks for both live in
`scripts/build-desktop-artifact.ts`, which is upstream-owned, is not one of the
seam ledger's rows, and which SEAMS.md:46 records the fork deliberately avoiding
for this very issue — serialisation was done in the workflow "rather than editing
build-desktop-artifact.ts". Spending a ledger row on the board's lowest-priority
item is a call worth making deliberately, so those are left open.
Refs #47
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@coderabbitai
coderabbitaiBot
commented
Aug 11, 2026

Copy link


Copy Markdown

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: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 6f950052-f743-48a5-9236-41bfa7c16985
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.
@radroidradroid
mentioned this pull request
Aug 11, 2026
 Merged

@radroid
radroid
merged commit da5c939
into
mainAug 12, 2026

2 checks passed

@radroid
radroid
deleted the

t3x/win-exit-diagnostics

branch
August 12, 2026 02:04
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@radroid

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
fix(t3x): the Windows transient-crash retry could never fire; classify on the code vp prints (#47) - #79
Merged
radroid merged 1 commit into
mainfrom 
t3x/win-exit-diagnostics
Aug 12, 2026
Merged
fix(t3x): the Windows transient-crash retry could never fire; classify on the code vp prints (#47)#79
radroid merged 1 commit into
mainfrom 
t3x/win-exit-diagnostics
Conversation
@radroid
@radroidradroid
commented
Aug 11, 2026

Copy link


Copy Markdown

Owner
Refs #47. This started as the issue's "translate these numeric exit codes into a readable diagnostic" item and turned up a live bug on the way.
The retry has been dead code since it was written
t3x-release.yml serialises the Windows desktop build and retries it three times when the failure looks like a Windows process-startup condition. The classifier was:
grep -qiE '0xC0000142|0xC0000005|STATUS_DLL_INIT_FAILED|Access violation'"$log"
The failure it was written for contains none of those. Verbatim from the issue:
[3] @t3tools/desktop#build: node scripts/build-preview-annotation-css.mjs FAILED (exit code: -1073741502)

-1073741502is0xC0000142 — as a signed 32-bit integer, which is how Node reports a child's status and therefore the only form that reaches the log. The hex spelling never appears anywhere.
So every attempt fell through to the not a known transient branch and exited. Checked rather than assumed — the old pattern run against the issue's log:
old grep against the observed log:
NO MATCH -> the retry could never have fired

The next occurrence would have cost the release the retry was added to protect.
What replaces it
scripts/t3x/windows-exit-codes.mjs matches all four spellings a status appears in (signed decimal, unsigned decimal, hex, NTSTATUS name) and also does the issue's other ask — it says what the status means, so a recurrence is diagnosed from the log instead of from a bare negative integer:
STATUS_DLL_INIT_FAILED (0xC0000142, reported by Node as -1073741502)
What it means: A DLL's initialisation routine failed while the process was starting, so the program never reached main().
Retryable: Usually desktop-heap or session resource pressure from spawning several processes at once. Retry, and prefer serialising the build over widening the pool.

It also distinguishes retryable from not, which a flat grep could not:
StatusRetry?
STATUS_DLL_INIT_FAILED · STATUS_ACCESS_VIOLATIONyes — both show up under concurrent-spawn pressure
STATUS_HEAP_CORRUPTION · STATUS_STACK_BUFFER_OVERRUNno — real bugs
STATUS_DLL_NOT_FOUND · STATUS_INVALID_IMAGE_FORMATno — deterministic, retrying cannot help
A log carrying more than one status is transient only if all of them are, so a heap corruption alongside a DLL-init failure stops the build rather than hiding behind another two minutes of compute.
The exit code is the interface — 0 retry, 1 stop — so the workflow keeps if node … --classify "$log"; then and parses nothing.
Two details the tests pin down
Both bit while writing this:
  • \b is wrong at both ends of the signed form. The leading - is a non-word character, so \b-1073741502 never matches after code: ; and a trailing \b still matches inside -10737415021. The explicit lookarounds are what stop a build id being read as a crash — there is a test for exactly that.
  • The fixture is the issue's log, not a log shape invented here. If the real output had been paraphrased into the test, the test would have passed against the broken grep too.
15 tests. tsgo --noEmit on scripts exits 0 (types come from a hand-written .d.mts, same as render-release-notes); vp test run on scripts is 216 passed; vp lint clean; workflow YAML parses. The classifier CLI was exercised against three log shapes — transient, real-bug, and ordinary-failure — and exits 0/1/1 as intended.
Scope, and one thing I did not do
This is the diagnostic half only. The build-failure and artifact-freshness contracts the issue's Test case needed section also asks for both live in scripts/build-desktop-artifact.ts — which is upstream-owned, is not one of the ledger's rows, and which SEAMS.md:46 records the fork deliberately avoiding for this very issue: serialisation was done with vp run --concurrency-limit 1 in the workflow "rather than editing build-desktop-artifact.ts".
The triage comment assumed the diagnostic was "a small, self-contained, platform-specific improvement with no seam cost". That holds for what is here, because the workflow is fork-owned — but it does not hold for those two contracts. Spending a ledger row on the board's lowest-priority item is your call, so I left them open rather than making it.
🤖 Generated with Claude Code
@radroid@claude
fix(t3x): the Windows transient-crash retry could never fire; classif…
abbbfcd
…y on the code vp prints (#47)
The release workflow serialises the Windows desktop build and retries it three
times when the failure looks like a Windows process-startup condition. The
classifier was:
grep -qiE '0xC0000142|0xC0000005|STATUS_DLL_INIT_FAILED|Access violation'
and the failure it was written for contains none of those. What vp actually
prints, verbatim from #47, is:
[3] @t3tools/desktop#build: node …/build-preview-annotation-css.mjs FAILED (exit code: -1073741502)
`-1073741502` is `0xC0000142` as a signed 32-bit integer, which is the form Node
reports a child's status in and therefore the only form that reaches the log. The
hex spelling never appears. So every attempt would have fallen through to the
`not a known transient` branch and exited — the retry has been dead code since it
was written, and the next occurrence would have cost the release it was added to
protect. Confirmed by running the old pattern against the issue's log: no match.
`scripts/t3x/windows-exit-codes.mjs` replaces it, matching all four spellings a
status can appear in (signed decimal, unsigned decimal, hex, NTSTATUS name), and
also does the other half of #47 — it says what the status means.
The table distinguishes retryable from not, which the grep could not:
STATUS_DLL_INIT_FAILED and STATUS_ACCESS_VIOLATION are worth another attempt
under concurrent-spawn pressure; STATUS_HEAP_CORRUPTION,
STATUS_STACK_BUFFER_OVERRUN, STATUS_DLL_NOT_FOUND and STATUS_INVALID_IMAGE_FORMAT
are not, and retrying those three times only makes a real failure slower to
diagnose. A log carrying more than one status is transient only if all of them
are, so a heap corruption alongside a DLL-init failure stops the build rather
than hiding behind another attempt.
Two details the tests pin down, both of which bit while writing this:
- `\b` is wrong at both ends of the signed form. The leading `-` is a non-word
character, so `\b-1073741502` never matches after `code: `; and a trailing
`\b` still matches inside `-10737415021`. The lookarounds are what stop a
build id being read as a crash.
- The classifier's exit code is the interface — 0 means retry, 1 means stop — so
the workflow keeps `if node … --classify "$log"; then` and parses nothing.
15 tests, built on the log pasted into the issue rather than on a log shape
invented here.
## Scope
This is the diagnostic half of #47. The build-failure and artifact-freshness
contracts its "Test case needed" section also asks for both live in
`scripts/build-desktop-artifact.ts`, which is upstream-owned, is not one of the
seam ledger's rows, and which SEAMS.md:46 records the fork deliberately avoiding
for this very issue — serialisation was done in the workflow "rather than editing
build-desktop-artifact.ts". Spending a ledger row on the board's lowest-priority
item is a call worth making deliberately, so those are left open.
Refs #47
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@coderabbitai
coderabbitaiBot
commented
Aug 11, 2026

Copy link


Copy Markdown

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: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 6f950052-f743-48a5-9236-41bfa7c16985
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.
@radroidradroid
mentioned this pull request
Aug 11, 2026
 Merged

@radroid
radroid
merged commit da5c939
into
mainAug 12, 2026

2 checks passed

@radroid
radroid
deleted the

t3x/win-exit-diagnostics

branch
August 12, 2026 02:04
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@radroid

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
fix(t3x): the Windows transient-crash retry could never fire; classify on the code vp prints (#47) - #79
Merged
radroid merged 1 commit into
mainfrom 
t3x/win-exit-diagnostics
Aug 12, 2026
Merged
fix(t3x): the Windows transient-crash retry could never fire; classify on the code vp prints (#47)#79
radroid merged 1 commit into
mainfrom 
t3x/win-exit-diagnostics
Conversation
@radroid
@radroidradroid
commented
Aug 11, 2026

Copy link


Copy Markdown

Owner
Refs #47. This started as the issue's "translate these numeric exit codes into a readable diagnostic" item and turned up a live bug on the way.
The retry has been dead code since it was written
t3x-release.yml serialises the Windows desktop build and retries it three times when the failure looks like a Windows process-startup condition. The classifier was:
grep -qiE '0xC0000142|0xC0000005|STATUS_DLL_INIT_FAILED|Access violation'"$log"
The failure it was written for contains none of those. Verbatim from the issue:
[3] @t3tools/desktop#build: node scripts/build-preview-annotation-css.mjs FAILED (exit code: -1073741502)

-1073741502is0xC0000142 — as a signed 32-bit integer, which is how Node reports a child's status and therefore the only form that reaches the log. The hex spelling never appears anywhere.
So every attempt fell through to the not a known transient branch and exited. Checked rather than assumed — the old pattern run against the issue's log:
old grep against the observed log:
NO MATCH -> the retry could never have fired

The next occurrence would have cost the release the retry was added to protect.
What replaces it
scripts/t3x/windows-exit-codes.mjs matches all four spellings a status appears in (signed decimal, unsigned decimal, hex, NTSTATUS name) and also does the issue's other ask — it says what the status means, so a recurrence is diagnosed from the log instead of from a bare negative integer:
STATUS_DLL_INIT_FAILED (0xC0000142, reported by Node as -1073741502)
What it means: A DLL's initialisation routine failed while the process was starting, so the program never reached main().
Retryable: Usually desktop-heap or session resource pressure from spawning several processes at once. Retry, and prefer serialising the build over widening the pool.

It also distinguishes retryable from not, which a flat grep could not:
StatusRetry?
STATUS_DLL_INIT_FAILED · STATUS_ACCESS_VIOLATIONyes — both show up under concurrent-spawn pressure
STATUS_HEAP_CORRUPTION · STATUS_STACK_BUFFER_OVERRUNno — real bugs
STATUS_DLL_NOT_FOUND · STATUS_INVALID_IMAGE_FORMATno — deterministic, retrying cannot help
A log carrying more than one status is transient only if all of them are, so a heap corruption alongside a DLL-init failure stops the build rather than hiding behind another two minutes of compute.
The exit code is the interface — 0 retry, 1 stop — so the workflow keeps if node … --classify "$log"; then and parses nothing.
Two details the tests pin down
Both bit while writing this:
  • \b is wrong at both ends of the signed form. The leading - is a non-word character, so \b-1073741502 never matches after code: ; and a trailing \b still matches inside -10737415021. The explicit lookarounds are what stop a build id being read as a crash — there is a test for exactly that.
  • The fixture is the issue's log, not a log shape invented here. If the real output had been paraphrased into the test, the test would have passed against the broken grep too.
15 tests. tsgo --noEmit on scripts exits 0 (types come from a hand-written .d.mts, same as render-release-notes); vp test run on scripts is 216 passed; vp lint clean; workflow YAML parses. The classifier CLI was exercised against three log shapes — transient, real-bug, and ordinary-failure — and exits 0/1/1 as intended.
Scope, and one thing I did not do
This is the diagnostic half only. The build-failure and artifact-freshness contracts the issue's Test case needed section also asks for both live in scripts/build-desktop-artifact.ts — which is upstream-owned, is not one of the ledger's rows, and which SEAMS.md:46 records the fork deliberately avoiding for this very issue: serialisation was done with vp run --concurrency-limit 1 in the workflow "rather than editing build-desktop-artifact.ts".
The triage comment assumed the diagnostic was "a small, self-contained, platform-specific improvement with no seam cost". That holds for what is here, because the workflow is fork-owned — but it does not hold for those two contracts. Spending a ledger row on the board's lowest-priority item is your call, so I left them open rather than making it.
🤖 Generated with Claude Code
@radroid@claude
fix(t3x): the Windows transient-crash retry could never fire; classif…
abbbfcd
…y on the code vp prints (#47)
The release workflow serialises the Windows desktop build and retries it three
times when the failure looks like a Windows process-startup condition. The
classifier was:
grep -qiE '0xC0000142|0xC0000005|STATUS_DLL_INIT_FAILED|Access violation'
and the failure it was written for contains none of those. What vp actually
prints, verbatim from #47, is:
[3] @t3tools/desktop#build: node …/build-preview-annotation-css.mjs FAILED (exit code: -1073741502)
`-1073741502` is `0xC0000142` as a signed 32-bit integer, which is the form Node
reports a child's status in and therefore the only form that reaches the log. The
hex spelling never appears. So every attempt would have fallen through to the
`not a known transient` branch and exited — the retry has been dead code since it
was written, and the next occurrence would have cost the release it was added to
protect. Confirmed by running the old pattern against the issue's log: no match.
`scripts/t3x/windows-exit-codes.mjs` replaces it, matching all four spellings a
status can appear in (signed decimal, unsigned decimal, hex, NTSTATUS name), and
also does the other half of #47 — it says what the status means.
The table distinguishes retryable from not, which the grep could not:
STATUS_DLL_INIT_FAILED and STATUS_ACCESS_VIOLATION are worth another attempt
under concurrent-spawn pressure; STATUS_HEAP_CORRUPTION,
STATUS_STACK_BUFFER_OVERRUN, STATUS_DLL_NOT_FOUND and STATUS_INVALID_IMAGE_FORMAT
are not, and retrying those three times only makes a real failure slower to
diagnose. A log carrying more than one status is transient only if all of them
are, so a heap corruption alongside a DLL-init failure stops the build rather
than hiding behind another attempt.
Two details the tests pin down, both of which bit while writing this:
- `\b` is wrong at both ends of the signed form. The leading `-` is a non-word
character, so `\b-1073741502` never matches after `code: `; and a trailing
`\b` still matches inside `-10737415021`. The lookarounds are what stop a
build id being read as a crash.
- The classifier's exit code is the interface — 0 means retry, 1 means stop — so
the workflow keeps `if node … --classify "$log"; then` and parses nothing.
15 tests, built on the log pasted into the issue rather than on a log shape
invented here.
## Scope
This is the diagnostic half of #47. The build-failure and artifact-freshness
contracts its "Test case needed" section also asks for both live in
`scripts/build-desktop-artifact.ts`, which is upstream-owned, is not one of the
seam ledger's rows, and which SEAMS.md:46 records the fork deliberately avoiding
for this very issue — serialisation was done in the workflow "rather than editing
build-desktop-artifact.ts". Spending a ledger row on the board's lowest-priority
item is a call worth making deliberately, so those are left open.
Refs #47
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@coderabbitai
coderabbitaiBot
commented
Aug 11, 2026

Copy link


Copy Markdown

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: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 6f950052-f743-48a5-9236-41bfa7c16985
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.
@radroidradroid
mentioned this pull request
Aug 11, 2026
 Merged

@radroid
radroid
merged commit da5c939
into
mainAug 12, 2026

2 checks passed

@radroid
radroid
deleted the

t3x/win-exit-diagnostics

branch
August 12, 2026 02:04
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@radroid

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
fix(t3x): the Windows transient-crash retry could never fire; classify on the code vp prints (#47) - #79
Merged
radroid merged 1 commit into
mainfrom 
t3x/win-exit-diagnostics
Aug 12, 2026
Merged
fix(t3x): the Windows transient-crash retry could never fire; classify on the code vp prints (#47)#79
radroid merged 1 commit into
mainfrom 
t3x/win-exit-diagnostics
Conversation
@radroid
@radroidradroid
commented
Aug 11, 2026

Copy link


Copy Markdown

Owner
Refs #47. This started as the issue's "translate these numeric exit codes into a readable diagnostic" item and turned up a live bug on the way.
The retry has been dead code since it was written
t3x-release.yml serialises the Windows desktop build and retries it three times when the failure looks like a Windows process-startup condition. The classifier was:
grep -qiE '0xC0000142|0xC0000005|STATUS_DLL_INIT_FAILED|Access violation'"$log"
The failure it was written for contains none of those. Verbatim from the issue:
[3] @t3tools/desktop#build: node scripts/build-preview-annotation-css.mjs FAILED (exit code: -1073741502)

-1073741502is0xC0000142 — as a signed 32-bit integer, which is how Node reports a child's status and therefore the only form that reaches the log. The hex spelling never appears anywhere.
So every attempt fell through to the not a known transient branch and exited. Checked rather than assumed — the old pattern run against the issue's log:
old grep against the observed log:
NO MATCH -> the retry could never have fired

The next occurrence would have cost the release the retry was added to protect.
What replaces it
scripts/t3x/windows-exit-codes.mjs matches all four spellings a status appears in (signed decimal, unsigned decimal, hex, NTSTATUS name) and also does the issue's other ask — it says what the status means, so a recurrence is diagnosed from the log instead of from a bare negative integer:
STATUS_DLL_INIT_FAILED (0xC0000142, reported by Node as -1073741502)
What it means: A DLL's initialisation routine failed while the process was starting, so the program never reached main().
Retryable: Usually desktop-heap or session resource pressure from spawning several processes at once. Retry, and prefer serialising the build over widening the pool.

It also distinguishes retryable from not, which a flat grep could not:
StatusRetry?
STATUS_DLL_INIT_FAILED · STATUS_ACCESS_VIOLATIONyes — both show up under concurrent-spawn pressure
STATUS_HEAP_CORRUPTION · STATUS_STACK_BUFFER_OVERRUNno — real bugs
STATUS_DLL_NOT_FOUND · STATUS_INVALID_IMAGE_FORMATno — deterministic, retrying cannot help
A log carrying more than one status is transient only if all of them are, so a heap corruption alongside a DLL-init failure stops the build rather than hiding behind another two minutes of compute.
The exit code is the interface — 0 retry, 1 stop — so the workflow keeps if node … --classify "$log"; then and parses nothing.
Two details the tests pin down
Both bit while writing this:
  • \b is wrong at both ends of the signed form. The leading - is a non-word character, so \b-1073741502 never matches after code: ; and a trailing \b still matches inside -10737415021. The explicit lookarounds are what stop a build id being read as a crash — there is a test for exactly that.
  • The fixture is the issue's log, not a log shape invented here. If the real output had been paraphrased into the test, the test would have passed against the broken grep too.
15 tests. tsgo --noEmit on scripts exits 0 (types come from a hand-written .d.mts, same as render-release-notes); vp test run on scripts is 216 passed; vp lint clean; workflow YAML parses. The classifier CLI was exercised against three log shapes — transient, real-bug, and ordinary-failure — and exits 0/1/1 as intended.
Scope, and one thing I did not do
This is the diagnostic half only. The build-failure and artifact-freshness contracts the issue's Test case needed section also asks for both live in scripts/build-desktop-artifact.ts — which is upstream-owned, is not one of the ledger's rows, and which SEAMS.md:46 records the fork deliberately avoiding for this very issue: serialisation was done with vp run --concurrency-limit 1 in the workflow "rather than editing build-desktop-artifact.ts".
The triage comment assumed the diagnostic was "a small, self-contained, platform-specific improvement with no seam cost". That holds for what is here, because the workflow is fork-owned — but it does not hold for those two contracts. Spending a ledger row on the board's lowest-priority item is your call, so I left them open rather than making it.
🤖 Generated with Claude Code
@radroid@claude
fix(t3x): the Windows transient-crash retry could never fire; classif…
abbbfcd
…y on the code vp prints (#47)
The release workflow serialises the Windows desktop build and retries it three
times when the failure looks like a Windows process-startup condition. The
classifier was:
grep -qiE '0xC0000142|0xC0000005|STATUS_DLL_INIT_FAILED|Access violation'
and the failure it was written for contains none of those. What vp actually
prints, verbatim from #47, is:
[3] @t3tools/desktop#build: node …/build-preview-annotation-css.mjs FAILED (exit code: -1073741502)
`-1073741502` is `0xC0000142` as a signed 32-bit integer, which is the form Node
reports a child's status in and therefore the only form that reaches the log. The
hex spelling never appears. So every attempt would have fallen through to the
`not a known transient` branch and exited — the retry has been dead code since it
was written, and the next occurrence would have cost the release it was added to
protect. Confirmed by running the old pattern against the issue's log: no match.
`scripts/t3x/windows-exit-codes.mjs` replaces it, matching all four spellings a
status can appear in (signed decimal, unsigned decimal, hex, NTSTATUS name), and
also does the other half of #47 — it says what the status means.
The table distinguishes retryable from not, which the grep could not:
STATUS_DLL_INIT_FAILED and STATUS_ACCESS_VIOLATION are worth another attempt
under concurrent-spawn pressure; STATUS_HEAP_CORRUPTION,
STATUS_STACK_BUFFER_OVERRUN, STATUS_DLL_NOT_FOUND and STATUS_INVALID_IMAGE_FORMAT
are not, and retrying those three times only makes a real failure slower to
diagnose. A log carrying more than one status is transient only if all of them
are, so a heap corruption alongside a DLL-init failure stops the build rather
than hiding behind another attempt.
Two details the tests pin down, both of which bit while writing this:
- `\b` is wrong at both ends of the signed form. The leading `-` is a non-word
character, so `\b-1073741502` never matches after `code: `; and a trailing
`\b` still matches inside `-10737415021`. The lookarounds are what stop a
build id being read as a crash.
- The classifier's exit code is the interface — 0 means retry, 1 means stop — so
the workflow keeps `if node … --classify "$log"; then` and parses nothing.
15 tests, built on the log pasted into the issue rather than on a log shape
invented here.
## Scope
This is the diagnostic half of #47. The build-failure and artifact-freshness
contracts its "Test case needed" section also asks for both live in
`scripts/build-desktop-artifact.ts`, which is upstream-owned, is not one of the
seam ledger's rows, and which SEAMS.md:46 records the fork deliberately avoiding
for this very issue — serialisation was done in the workflow "rather than editing
build-desktop-artifact.ts". Spending a ledger row on the board's lowest-priority
item is a call worth making deliberately, so those are left open.
Refs #47
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@coderabbitai
coderabbitaiBot
commented
Aug 11, 2026

Copy link


Copy Markdown

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: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 6f950052-f743-48a5-9236-41bfa7c16985
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.
@radroidradroid
mentioned this pull request
Aug 11, 2026
 Merged

@radroid
radroid
merged commit da5c939
into
mainAug 12, 2026

2 checks passed

@radroid
radroid
deleted the

t3x/win-exit-diagnostics

branch
August 12, 2026 02:04
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@radroid

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
fix(t3x): the Windows transient-crash retry could never fire; classify on the code vp prints (#47) - #79
Merged
radroid merged 1 commit into
mainfrom 
t3x/win-exit-diagnostics
Aug 12, 2026
Merged
fix(t3x): the Windows transient-crash retry could never fire; classify on the code vp prints (#47)#79
radroid merged 1 commit into
mainfrom 
t3x/win-exit-diagnostics
Conversation
@radroid
@radroidradroid
commented
Aug 11, 2026

Copy link


Copy Markdown

Owner
Refs #47. This started as the issue's "translate these numeric exit codes into a readable diagnostic" item and turned up a live bug on the way.
The retry has been dead code since it was written
t3x-release.yml serialises the Windows desktop build and retries it three times when the failure looks like a Windows process-startup condition. The classifier was:
grep -qiE '0xC0000142|0xC0000005|STATUS_DLL_INIT_FAILED|Access violation'"$log"
The failure it was written for contains none of those. Verbatim from the issue:
[3] @t3tools/desktop#build: node scripts/build-preview-annotation-css.mjs FAILED (exit code: -1073741502)

-1073741502is0xC0000142 — as a signed 32-bit integer, which is how Node reports a child's status and therefore the only form that reaches the log. The hex spelling never appears anywhere.
So every attempt fell through to the not a known transient branch and exited. Checked rather than assumed — the old pattern run against the issue's log:
old grep against the observed log:
NO MATCH -> the retry could never have fired

The next occurrence would have cost the release the retry was added to protect.
What replaces it
scripts/t3x/windows-exit-codes.mjs matches all four spellings a status appears in (signed decimal, unsigned decimal, hex, NTSTATUS name) and also does the issue's other ask — it says what the status means, so a recurrence is diagnosed from the log instead of from a bare negative integer:
STATUS_DLL_INIT_FAILED (0xC0000142, reported by Node as -1073741502)
What it means: A DLL's initialisation routine failed while the process was starting, so the program never reached main().
Retryable: Usually desktop-heap or session resource pressure from spawning several processes at once. Retry, and prefer serialising the build over widening the pool.

It also distinguishes retryable from not, which a flat grep could not:
StatusRetry?
STATUS_DLL_INIT_FAILED · STATUS_ACCESS_VIOLATIONyes — both show up under concurrent-spawn pressure
STATUS_HEAP_CORRUPTION · STATUS_STACK_BUFFER_OVERRUNno — real bugs
STATUS_DLL_NOT_FOUND · STATUS_INVALID_IMAGE_FORMATno — deterministic, retrying cannot help
A log carrying more than one status is transient only if all of them are, so a heap corruption alongside a DLL-init failure stops the build rather than hiding behind another two minutes of compute.
The exit code is the interface — 0 retry, 1 stop — so the workflow keeps if node … --classify "$log"; then and parses nothing.
Two details the tests pin down
Both bit while writing this:
  • \b is wrong at both ends of the signed form. The leading - is a non-word character, so \b-1073741502 never matches after code: ; and a trailing \b still matches inside -10737415021. The explicit lookarounds are what stop a build id being read as a crash — there is a test for exactly that.
  • The fixture is the issue's log, not a log shape invented here. If the real output had been paraphrased into the test, the test would have passed against the broken grep too.
15 tests. tsgo --noEmit on scripts exits 0 (types come from a hand-written .d.mts, same as render-release-notes); vp test run on scripts is 216 passed; vp lint clean; workflow YAML parses. The classifier CLI was exercised against three log shapes — transient, real-bug, and ordinary-failure — and exits 0/1/1 as intended.
Scope, and one thing I did not do
This is the diagnostic half only. The build-failure and artifact-freshness contracts the issue's Test case needed section also asks for both live in scripts/build-desktop-artifact.ts — which is upstream-owned, is not one of the ledger's rows, and which SEAMS.md:46 records the fork deliberately avoiding for this very issue: serialisation was done with vp run --concurrency-limit 1 in the workflow "rather than editing build-desktop-artifact.ts".
The triage comment assumed the diagnostic was "a small, self-contained, platform-specific improvement with no seam cost". That holds for what is here, because the workflow is fork-owned — but it does not hold for those two contracts. Spending a ledger row on the board's lowest-priority item is your call, so I left them open rather than making it.
🤖 Generated with Claude Code
@radroid@claude
fix(t3x): the Windows transient-crash retry could never fire; classif…
abbbfcd
…y on the code vp prints (#47)
The release workflow serialises the Windows desktop build and retries it three
times when the failure looks like a Windows process-startup condition. The
classifier was:
grep -qiE '0xC0000142|0xC0000005|STATUS_DLL_INIT_FAILED|Access violation'
and the failure it was written for contains none of those. What vp actually
prints, verbatim from #47, is:
[3] @t3tools/desktop#build: node …/build-preview-annotation-css.mjs FAILED (exit code: -1073741502)
`-1073741502` is `0xC0000142` as a signed 32-bit integer, which is the form Node
reports a child's status in and therefore the only form that reaches the log. The
hex spelling never appears. So every attempt would have fallen through to the
`not a known transient` branch and exited — the retry has been dead code since it
was written, and the next occurrence would have cost the release it was added to
protect. Confirmed by running the old pattern against the issue's log: no match.
`scripts/t3x/windows-exit-codes.mjs` replaces it, matching all four spellings a
status can appear in (signed decimal, unsigned decimal, hex, NTSTATUS name), and
also does the other half of #47 — it says what the status means.
The table distinguishes retryable from not, which the grep could not:
STATUS_DLL_INIT_FAILED and STATUS_ACCESS_VIOLATION are worth another attempt
under concurrent-spawn pressure; STATUS_HEAP_CORRUPTION,
STATUS_STACK_BUFFER_OVERRUN, STATUS_DLL_NOT_FOUND and STATUS_INVALID_IMAGE_FORMAT
are not, and retrying those three times only makes a real failure slower to
diagnose. A log carrying more than one status is transient only if all of them
are, so a heap corruption alongside a DLL-init failure stops the build rather
than hiding behind another attempt.
Two details the tests pin down, both of which bit while writing this:
- `\b` is wrong at both ends of the signed form. The leading `-` is a non-word
character, so `\b-1073741502` never matches after `code: `; and a trailing
`\b` still matches inside `-10737415021`. The lookarounds are what stop a
build id being read as a crash.
- The classifier's exit code is the interface — 0 means retry, 1 means stop — so
the workflow keeps `if node … --classify "$log"; then` and parses nothing.
15 tests, built on the log pasted into the issue rather than on a log shape
invented here.
## Scope
This is the diagnostic half of #47. The build-failure and artifact-freshness
contracts its "Test case needed" section also asks for both live in
`scripts/build-desktop-artifact.ts`, which is upstream-owned, is not one of the
seam ledger's rows, and which SEAMS.md:46 records the fork deliberately avoiding
for this very issue — serialisation was done in the workflow "rather than editing
build-desktop-artifact.ts". Spending a ledger row on the board's lowest-priority
item is a call worth making deliberately, so those are left open.
Refs #47
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@coderabbitai
coderabbitaiBot
commented
Aug 11, 2026

Copy link


Copy Markdown

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: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 6f950052-f743-48a5-9236-41bfa7c16985
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.
@radroidradroid
mentioned this pull request
Aug 11, 2026
 Merged

@radroid
radroid
merged commit da5c939
into
mainAug 12, 2026

2 checks passed

@radroid
radroid
deleted the

t3x/win-exit-diagnostics

branch
August 12, 2026 02:04
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@radroid

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
fix(t3x): the Windows transient-crash retry could never fire; classify on the code vp prints (#47) - #79
Merged
radroid merged 1 commit into
mainfrom 
t3x/win-exit-diagnostics
Aug 12, 2026
Merged
fix(t3x): the Windows transient-crash retry could never fire; classify on the code vp prints (#47)#79
radroid merged 1 commit into
mainfrom 
t3x/win-exit-diagnostics
Conversation
@radroid
@radroidradroid
commented
Aug 11, 2026

Copy link


Copy Markdown

Owner
Refs #47. This started as the issue's "translate these numeric exit codes into a readable diagnostic" item and turned up a live bug on the way.
The retry has been dead code since it was written
t3x-release.yml serialises the Windows desktop build and retries it three times when the failure looks like a Windows process-startup condition. The classifier was:
grep -qiE '0xC0000142|0xC0000005|STATUS_DLL_INIT_FAILED|Access violation'"$log"
The failure it was written for contains none of those. Verbatim from the issue:
[3] @t3tools/desktop#build: node scripts/build-preview-annotation-css.mjs FAILED (exit code: -1073741502)

-1073741502is0xC0000142 — as a signed 32-bit integer, which is how Node reports a child's status and therefore the only form that reaches the log. The hex spelling never appears anywhere.
So every attempt fell through to the not a known transient branch and exited. Checked rather than assumed — the old pattern run against the issue's log:
old grep against the observed log:
NO MATCH -> the retry could never have fired

The next occurrence would have cost the release the retry was added to protect.
What replaces it
scripts/t3x/windows-exit-codes.mjs matches all four spellings a status appears in (signed decimal, unsigned decimal, hex, NTSTATUS name) and also does the issue's other ask — it says what the status means, so a recurrence is diagnosed from the log instead of from a bare negative integer:
STATUS_DLL_INIT_FAILED (0xC0000142, reported by Node as -1073741502)
What it means: A DLL's initialisation routine failed while the process was starting, so the program never reached main().
Retryable: Usually desktop-heap or session resource pressure from spawning several processes at once. Retry, and prefer serialising the build over widening the pool.

It also distinguishes retryable from not, which a flat grep could not:
StatusRetry?
STATUS_DLL_INIT_FAILED · STATUS_ACCESS_VIOLATIONyes — both show up under concurrent-spawn pressure
STATUS_HEAP_CORRUPTION · STATUS_STACK_BUFFER_OVERRUNno — real bugs
STATUS_DLL_NOT_FOUND · STATUS_INVALID_IMAGE_FORMATno — deterministic, retrying cannot help
A log carrying more than one status is transient only if all of them are, so a heap corruption alongside a DLL-init failure stops the build rather than hiding behind another two minutes of compute.
The exit code is the interface — 0 retry, 1 stop — so the workflow keeps if node … --classify "$log"; then and parses nothing.
Two details the tests pin down
Both bit while writing this:
  • \b is wrong at both ends of the signed form. The leading - is a non-word character, so \b-1073741502 never matches after code: ; and a trailing \b still matches inside -10737415021. The explicit lookarounds are what stop a build id being read as a crash — there is a test for exactly that.
  • The fixture is the issue's log, not a log shape invented here. If the real output had been paraphrased into the test, the test would have passed against the broken grep too.
15 tests. tsgo --noEmit on scripts exits 0 (types come from a hand-written .d.mts, same as render-release-notes); vp test run on scripts is 216 passed; vp lint clean; workflow YAML parses. The classifier CLI was exercised against three log shapes — transient, real-bug, and ordinary-failure — and exits 0/1/1 as intended.
Scope, and one thing I did not do
This is the diagnostic half only. The build-failure and artifact-freshness contracts the issue's Test case needed section also asks for both live in scripts/build-desktop-artifact.ts — which is upstream-owned, is not one of the ledger's rows, and which SEAMS.md:46 records the fork deliberately avoiding for this very issue: serialisation was done with vp run --concurrency-limit 1 in the workflow "rather than editing build-desktop-artifact.ts".
The triage comment assumed the diagnostic was "a small, self-contained, platform-specific improvement with no seam cost". That holds for what is here, because the workflow is fork-owned — but it does not hold for those two contracts. Spending a ledger row on the board's lowest-priority item is your call, so I left them open rather than making it.
🤖 Generated with Claude Code
@radroid@claude
fix(t3x): the Windows transient-crash retry could never fire; classif…
abbbfcd
…y on the code vp prints (#47)
The release workflow serialises the Windows desktop build and retries it three
times when the failure looks like a Windows process-startup condition. The
classifier was:
grep -qiE '0xC0000142|0xC0000005|STATUS_DLL_INIT_FAILED|Access violation'
and the failure it was written for contains none of those. What vp actually
prints, verbatim from #47, is:
[3] @t3tools/desktop#build: node …/build-preview-annotation-css.mjs FAILED (exit code: -1073741502)
`-1073741502` is `0xC0000142` as a signed 32-bit integer, which is the form Node
reports a child's status in and therefore the only form that reaches the log. The
hex spelling never appears. So every attempt would have fallen through to the
`not a known transient` branch and exited — the retry has been dead code since it
was written, and the next occurrence would have cost the release it was added to
protect. Confirmed by running the old pattern against the issue's log: no match.
`scripts/t3x/windows-exit-codes.mjs` replaces it, matching all four spellings a
status can appear in (signed decimal, unsigned decimal, hex, NTSTATUS name), and
also does the other half of #47 — it says what the status means.
The table distinguishes retryable from not, which the grep could not:
STATUS_DLL_INIT_FAILED and STATUS_ACCESS_VIOLATION are worth another attempt
under concurrent-spawn pressure; STATUS_HEAP_CORRUPTION,
STATUS_STACK_BUFFER_OVERRUN, STATUS_DLL_NOT_FOUND and STATUS_INVALID_IMAGE_FORMAT
are not, and retrying those three times only makes a real failure slower to
diagnose. A log carrying more than one status is transient only if all of them
are, so a heap corruption alongside a DLL-init failure stops the build rather
than hiding behind another attempt.
Two details the tests pin down, both of which bit while writing this:
- `\b` is wrong at both ends of the signed form. The leading `-` is a non-word
character, so `\b-1073741502` never matches after `code: `; and a trailing
`\b` still matches inside `-10737415021`. The lookarounds are what stop a
build id being read as a crash.
- The classifier's exit code is the interface — 0 means retry, 1 means stop — so
the workflow keeps `if node … --classify "$log"; then` and parses nothing.
15 tests, built on the log pasted into the issue rather than on a log shape
invented here.
## Scope
This is the diagnostic half of #47. The build-failure and artifact-freshness
contracts its "Test case needed" section also asks for both live in
`scripts/build-desktop-artifact.ts`, which is upstream-owned, is not one of the
seam ledger's rows, and which SEAMS.md:46 records the fork deliberately avoiding
for this very issue — serialisation was done in the workflow "rather than editing
build-desktop-artifact.ts". Spending a ledger row on the board's lowest-priority
item is a call worth making deliberately, so those are left open.
Refs #47
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@coderabbitai
coderabbitaiBot
commented
Aug 11, 2026

Copy link


Copy Markdown

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: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 6f950052-f743-48a5-9236-41bfa7c16985
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.
@radroidradroid
mentioned this pull request
Aug 11, 2026
 Merged

@radroid
radroid
merged commit da5c939
into
mainAug 12, 2026

2 checks passed

@radroid
radroid
deleted the

t3x/win-exit-diagnostics

branch
August 12, 2026 02:04
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

1 participant

@radroid