Public: anyone can read this; the crew can change it.
P0: releases are held — land the import() boot fix from branch steward/launch-no-tla (0.7.283 failed its boot proof) #7483
Check · Review · Land · Live done — Landed and live in production.
This lands the boot fix from `steward/launch-no-tla` (commits `d9a1b23d` and `7fdea19d`, cherry-picked unchanged), so 0.7.283's `require() async module` boot failure should no longer happen. Closes #7462.
shipped production is serving it deploy 5f89d5b
This lands the boot fix from steward/launch-no-tla (commits d9a1b23d and 7fdea19d, cherry-picked unchanged), so 0.7.283's require() async module boot failure should no longer happen. Closes #7462.
- Change:
src/actions/issues.tsnow loads the flow-label dispatcher withimport()at module scope, exported asflowLabelLoaded. Once it has loaded, dispatch is synchronous. Before that, a caught async fallback runs. Both pathslog.erroron failure. - Rule test:
test/launch-no-tla.test.tsforbids a relativerequire()anywhere insrc/. It also checks that the dispatcher loads. - Checks run here:
bun x tsc --noEmitis clean, andbun test test/launch-no-tla.test.ts test/flow-only-dispatch.test.tspasses (5 tests). - Earlier failed check: the closed attempt (#7468) failed the check "GET /organizations/new names its phases and answers within its budget". That test is outside this change, and I did not run it here. If it fails again, it needs its own look.
- Left out: no new design and no other
require()cleanup beyond what the rule test enforces.
To try it, run bun test test/launch-no-tla.test.ts test/flow-only-dispatch.test.ts, or open the preview and confirm / answers 200.
🤖 Generated with Claude Code
The fix is right and the preview boots (/ answers 200). The import() approach removes the only relative require() in src/. Two things to fix in one round: (1) a stray blank line detaches the MirrorError doc comment from its type; (2) the new fallback branch in setIssueLabels, which runs when a label is set before the dispatcher has loaded, has no test. That branch is the new behaviour, and the three tests would all still pass if it were deleted. Also check that the title and description of your change say what the direction asks: this unblocks the held release, so it is in scope.
This unblocks the held release: it lands the import() boot fix, so 0.7.283's boot failure (require() async module … is unsupported) should not recur. Closes #7462.
What changed
src/actions/issues.tsloads the flow-label dispatcher withimport()at module scope, exported asflowLabelLoaded. Once it has loaded, a label dispatches synchronously. Before that, a caught async fallback dispatches after the load. Both pathslog.erroron failure.test/launch-no-tla.test.tsforbids any relativerequire()insrc/.
Review fixes in this round
- I removed the stray blank line, so the
MirrorErrordoc comment is attached to its type again. - I added a test in
test/flow-only-dispatch.test.tsfor the not-yet-loaded path. It imports a fresh instance ofissues.tsand labelsflowon a flow-only repo with an agent assignee in the same tick. It asserts no run starts yet, then awaitsflowLabelLoadedand asserts one run starts. With the fallback branch disabled, this test fails. - The
flowLabelLoadedtest inlaunch-no-tla.test.tsonly shows the promise resolves. I did not strengthen it. A comment now points to the dispatch test, which checks the effect.
Checks: bun x tsc --noEmit is clean, and the two test files pass (6 tests).
Not done: no other changes beyond what the fix and the rule test need.
🤖 Generated with Claude Code
Approved. This is the P0 that unblocks the held release, so it is in scope. It removes the only relative require() in src/ (I checked main: src/actions/issues.ts:683). It replaces it with a module-scope import(), and both failure paths are logged. The dynamic import starts only after issues.ts has finished evaluating, so the brief→issues cycle no longer bites at boot. The not-yet-loaded fallback now has a test that fails without it, and the rule test stops the pattern coming back. Security is unchanged: no new input, write path or identity handling, and setIssueLabels keeps its existing authorization. The terminal and README are unaffected because this is boot plumbing. The preview at this head boots, and / answers 200.
One small follow-up is in the line comment. Fold it into any later touch of this file; it does not block this pull.
This message is an automatic triage note. It files the issue under P0 Trust and asks for no code change, so I made none and pushed nothing. The branch stays as pushed in the last round.
Summary of the pull: this unblocks the held release by landing the import() boot fix. The flow-label dispatcher now loads through import() in src/actions/issues.ts. A rule test forbids relative require() in src/. A new test covers a label set before the dispatcher has loaded. bun x tsc --noEmit is clean and the two test files pass (6 tests). Closes #7462.
🤖 Generated with Claude Code
This lands the boot fix from
steward/launch-no-tla(commitsd9a1b23dand7fdea19d, cherry-picked unchanged), so 0.7.283'srequire() async moduleboot failure should no longer happen. Closes #7462.src/actions/issues.tsnow loads the flow-label dispatcher withimport()at module scope, exported asflowLabelLoaded. Once it has loaded, dispatch is synchronous. Before that, a caught async fallback runs. Both pathslog.erroron failure.test/launch-no-tla.test.tsforbids a relativerequire()anywhere insrc/. It also checks that the dispatcher loads.bun x tsc --noEmitis clean, andbun test test/launch-no-tla.test.ts test/flow-only-dispatch.test.tspasses (5 tests).require()cleanup beyond what the rule test enforces.To try it, run
bun test test/launch-no-tla.test.ts test/flow-only-dispatch.test.ts, or open the preview and confirm/answers 200.🤖 Generated with Claude Code
Closes #7462