MotirBuilding in public
MOTIR · moooon
onMotir
You’re viewing a public project. Anyone can view it — no account needed. Sign in to submit, upvote, or comment on requests.View-only — you can’t edit work items
MOTIR-3915

(motir-core) `roadmap-flow.spec.ts`'s seed races the status-derivation job — the SECOND spec in this class, and `retries: 1` made the run green

To Do
Description

Type · test (E2E flake) · Parent · MOTIR-1464 · Repo · motir-core · Found on · run 33260551040, job Playwright E2E (bulk-1), while measuring per-spec cost for MOTIR-3913 (PR #2457)

The observation

✘  42 [chromium] › tests/e2e/roadmap-flow.spec.ts:60:5 › Roadmap: open from the left-nav
      entry, see the markers, drill into an epic and back (34.2s)
✓  43 [chromium] › tests/e2e/roadmap-flow.spec.ts:60:5 › … (retry #1) (5.1s)

Error: seed: derived status "in_progress" never landed on cmtejxus502gpb72bzfgfp2qo (saw "done")
  > 120 |       throw new Error(

The throw is in the spec's own seed(), not in an assertion: the fixture waits for a derived in_progress to land on an item and observes done instead, then times out at 34.2 s. The retry passed in 5.1 s and the run went green.

Why it is filed rather than re-run

It is the second spec in a class this repository has already diagnosed once. tests/e2e/follow-the-build-flow.spec.ts:132 was the first (2026-08-29, PR #2447 / MOTIR-3859, run 33223925559): there the seed's status walk in_progress → in_review → done lost to parentStatusRollupService completing the parent underneath it, and done → in_review is not a legal edge. Same two actors, opposite direction, same root — a fixture that asserts on a status the derivation job is concurrently recomputing. One instance is a flake; two in different specs is a pattern the fixtures owe a fix for, which is what this card is.

The standing repair named on that diagnosis applies unchanged: the SEED is what should wait, not the product. A fixture that reads back a derived status has to settle the derivation (or arrange the ordering so no recompute is in flight), rather than assume the value it wrote is the value it will read.

Why nothing caught it

retries: 1 masked it — the check surface reported a green E2E leg. It was found only by reading the harness e2e-harness/*.jsonl records while auditing per-spec cost for MOTIR-3913: the spec read 5.7 s on run 33251966134 and 42.3 s on 33260551040, a 7.4x swing that is one failed attempt plus one passing one rather than a spec that got slower.

That is a transferable finding for any cost-based shard plan: a retry inflates a spec's measured cost invisibly, so a leg that overshoots its predicted budget is worth checking for a masked failure before it is written off as drift.

Not caused by the diff it was found on

PR #2457 re-shards the E2E bulk legs 5 → 8 and touches tests/e2e/shard-plan.ts, its guard, and ci.yml — no line of roadmap-flow.spec.ts, parentStatusRollupService or the statusDerivation job. Stated fairly rather than dismissed: re-sharding does move a spec to a different leg, hence a different server and a different ordering, and that changes the timing a race is exposed to. It widens or narrows the window; it does not create one. The failure mode and its error string are the same ones the earlier instance produced on an unrelated diff.

Acceptance criteria

  1. roadmap-flow.spec.ts's seed no longer reads back a status the derivation job can be recomputing — it settles the derivation, or orders the writes so none is in flight. The specific wait is named in a comment, with the actor it is waiting on.
  2. The same audit is applied to the other fixtures that read back a derived status. Name the ones checked, including the ones found clean — a sweep that reports only its hits cannot be distinguished from a sweep that stopped early.
  3. The spec passes 5 consecutive times on CI at retry 0, evidenced from the harness jsonl (a green run is not evidence here — retries: 1 is exactly what hid this).
  4. follow-the-build-flow.spec.ts is either fixed by the same change or explicitly stated as still owing its own repair, so the class does not close on one of its two instances.

Out of scope

  • Changing retries: 1. It is doing its job for genuine infrastructure blips; the problem is that a masked failure has no other reader, which is a reporting gap and its own question.
  • The derivation job's own behaviour. It carries three race repairs already (MOTIR-3334, MOTIR-2902, MOTIR-3015); this card is about fixtures that race it, not about the job.

Context refs

  • tests/e2e/roadmap-flow.spec.ts:60, and its seed() around line 120 (the throw).
  • tests/e2e/follow-the-build-flow.spec.ts:69,132 — the first instance.
  • lib/services/parentStatusRollupService.ts, lib/jobs/definitions/statusDerivation.ts — the other actor.
  • Run 33260551040, job Playwright E2E (bulk-1); the playwright-report-bulk-1 artifact's e2e-harness/*.jsonl carries the two attempts with their durations.

Resolution: open.