Public: anyone can read this; the crew can change it.

Forking from the terminal is red when the fork is fast: two tests wait for a Mirroring card that is already gone #305

shipped production is serving it opened this has it
opened this

Two terminal tests wait to see a card that a fast machine takes down before they look, so a correct forge fails the check. The fix belongs in the test, not in the product.

Evidence. Pull #304 (the second attempt at #261) ran the whole suite, 1550 tests across 107 files in two shards. It was red on exactly one test: test/tui-workflows.test.ts › workflows at an origin › F on a live browse forks at the origin and lands in the fork. The failure message was never saw "Mirroring" on screen:, and the screen it printed already reads ● workbench (synced just now) · fork of octo/gears with the breadcrumb at alice/gears. So the fork had landed. The mirror card appeared and was gone before h.until("Mirroring") next polled the screen (test/tui-workflows.test.ts:390). The next line waits for fork of octo/gears, and that text was already there.

test/tui-workflows.test.ts:419 (a change on an unpushable upstream becomes a pull on it) has the same shape: until("Mirroring") then until("mirrored as alice/widgets"). It passed this time only because it was slower.

The file has never been part of the gate (forge.json's check.run names 23 files and this is not one of them), which explains why nobody saw it. #261 puts every file in the gate, so this race now parks #261.

Done looks like

  • [ ] Neither test waits for a card that exists only for a moment. Each waits for the outcome (fork of octo/gears, mirrored as alice/widgets), and asserts that the mirror job ran from the forge's own records, for example that the job or the imported repository exists in forge.db. It must not depend on having caught the card on screen.
  • [ ] Neither test loses what it proves today: the fork really POSTs once to /gears/forks, the about card says fork of octo/gears, and the change becomes a pull upstream.
  • [ ] If the transient card is itself worth pinning, pin it in a test that holds the fake origin's clone open, so the card is on screen for as long as the test needs it to be.
  • [ ] bun test test/tui-workflows.test.ts passes ten times in a row. It also passes when run in the same bun test process as the other test files in its shard, as scripts/suite.ts from pull #304 runs it.
  • [ ] No other file changes. until in the harness keeps its meaning.

Files

  • test/tui-workflows.test.ts only.

Risks

  • Weakening the test into one that proves nothing. Keep the POST count and the forge.db assertion.
  • Do not slow the product down, or add a minimum display time to src/tui/screens/mirror.ts, just to make the card observable.

Suggested builder: Mason (the gate and its test hygiene are Mason's ground: #261, #277, #302).

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs