finding(timeline): ObjectTimeline.colorFieldLadder-7243 rung 2 returned the PREVIOUS call's colour — two awaits in one test, the second got the first's value

[os-sales]

Filed unassigned by the domain:devx execution seat (session session_019aCUUSwWefnbCJ4Xk1vqQW, R41) after it turned PR #7458 red. ⛔ No domain:* label — routing is the triage seat's to produce. The seat that hit it is a docs lane and does not own plugin-timeline.

Measured

packages/plugin-timeline/src/ObjectTimeline.colorFieldLadder-7243.test.tsx:109, on GitHub Actions run 33725412699, job Test (shard 3/4), 2026-09-03T07:05Z:

AssertionError: expected [ '#abc' ] to deeply equal [ '#123456' ]

The test body is a pair of consecutive awaits in one it:

it('rung 2: 3- and 6-digit hex literals pass through', async () => {
 expect(await colorsFor('accent', [{ ...ROW, accent: '#abc' }])).toEqual(['#abc']);
 expect(await colorsFor('accent', [{ ...ROW, accent: '#123456' }])).toEqual(['#123456']);
});

The first assertion passed. The second returned ['#abc'] — the value the first call produced. So this is not a wrong expectation and not a colour-parsing bug: the second invocation served the first invocation's result.

That is one of two shapes, and they need different fixes:

1. Memoisation keyed too coarsely — a cache inside the shared ladder keyed on the field name ('accent') rather than on the row values, so the second call hits the first's entry. Deterministic, and it would fail every run, which the surrounding history argues against.
2. Async settlement — colorsFor resolves before the component has re-rendered for the second input, so the assertion reads the previous render's output. Timing-dependent, therefore intermittent, which matches this being the first observed failure.

⇒ Whoever picks this up should establish which before changing anything; a fix for (1) applied to (2) will look like it worked and will keep failing under load.

Why it is worth a card rather than a re-run

The test arrived with e75f4c986 — "fix(gantt,calendar,timeline): resolve colorField through one shared ladder (#7338)". Consolidating three plugins onto one shared resolution path is precisely the change that introduces cross-call state, and the ladder is now shared by gantt, calendar and timeline — so if this is (1), the same defect is reachable from three plugins and only one of them has a test that happened to call it twice in a row.

⚠️ It is also a shared-resource problem, not one PR's: while it fails, it fails on every PR whose shard 3 includes this file. It surfaced on a docs-only PR (#7458) that touches no runtime source at all, which is how a repo learns that a test is nondeterministic — the diff could not possibly have caused it.

⛔ Recorded so nobody is tempted by the cheap exits: the fix is not to skip, quarantine or retry the test, and not to split the two assertions into separate it blocks — splitting would hide the defect by removing the only call sequence that exposes it, while leaving the shared ladder's real behaviour unchanged for the three plugins that use it.

Scope if picked up

packages/plugin-timeline/src/ObjectTimeline.colorFieldLadder-7243.test.tsx and whatever the shared colorField ladder resolves through (introduced by #7338, shared with plugin-gantt and plugin-calendar). The reproduction lever is a second call with a different value for the same field in the same test.

Back-links: PR #7458 (where it surfaced, with the seat's standing-down comment) · #7338 / e75f4c986 (which introduced the shared ladder and this test) · #7243 (the card the test is named for).

[os-sales]

Second reading: the re-run PASSED — which discriminates between this card's two hypotheses

domain:devx seat (session session_019aCUUSwWefnbCJ4Xk1vqQW), following up the failure that produced this card.

Run 33725412699, attempt 2, same commit b701323ec, no code change of any kind between attempts: Test (shard 3/4) = success. The PR converged 26 green / 3 skipped / 0 red.

What that buys, and what it does not

⛔ It does not mean the defect is absent — an intermittent failure that passes on retry is still a defect, and the whole reason this card exists is that it is invisible between failures.

What it does buy is discrimination between the two shapes this card names:

hypothesis	prediction under re-run	observed
1 — memoisation keyed too coarsely (cache keyed on the field name 'accent' rather than the row values)	fails every run, deterministically: the second call would always hit the first's entry	❌ contradicted
2 — async settlement (colorsFor resolves before the component re-renders for the second input)	fails intermittently, depending on timing and machine load	✅ consistent

⇒ The evidence now favours hypothesis 2, and hypothesis 1 is close to ruled out — a same-commit re-run that flips red to green is very hard to reconcile with a deterministic cache-key bug.

⚠️ Stated as a shift in the evidence, not as a diagnosis: one passing re-run is a single sample, and a coarse cache combined with a nondeterministic iteration or cleanup order could in principle produce the same pattern. Whoever picks this up should still establish the mechanism directly rather than inheriting this table — but the cheap experiment is now obvious: run this one test file in a loop and see whether the failure rate is timing-shaped, and if so, look at how colorsFor awaits the render rather than at cache keys.

The consequence for the fix is real: a fix aimed at (1) — tightening a cache key — applied to a tree where (2) is the truth would look like it worked, pass CI, and keep failing under load. That was already written on this card before the re-run; the re-run has now made it the likelier trap rather than the unlikelier one.

Housekeeping

PR #7458 (the docs-only batch that surfaced this) is green and released to the merge queue. This card is unaffected by that and stays open on its own merits — it is a plugin-timeline defect, shared with plugin-gantt and plugin-calendar through the ladder #7338 introduced, and it remains unassigned for triage to route.

---

Generated by Claude Code