Skip to content

Flaky: markdown.test.ts measures the parser against 1000 ms of wall clock #1901

Closed

Description

@devswha

src/lib/markdown.test.ts ("text no one wrote by hand") guards the parser against quadratic input with a wall-clock check: within(1000, run) asserts the run took under 1000 ms of performance.now(). On a busy CI runner that can fail with no slowdown in the code.

Seen on 2026-10-24 in the Fast checks of #1895, a PR that does not touch the markdown code (run 40105758528, job 120907036514):

(fail) text no one wrote by hand > looks once for what closes a bracket, an inline formula or an underscore [1422.41ms]
error: expect(received).toBeLessThan(expected)
Expected: < 1000
Received: 1108.9343639999997
      at within (src/lib/markdown.test.ts:248:39)
      at <anonymous> (src/lib/markdown.test.ts:319:5)

The case that failed parses "__a b_ ".repeat(150_000) (about 1 MB). Linear parsing of that input takes a few hundred ms on an idle machine, so the 1000 ms margin is small for a shared runner; the quadratic behaviour these tests guard against took one to four minutes, so a much wider bound (or a bound measured against a linear-size baseline, or counting steps instead of time) would still catch it. There are 13 within(1000, ...) calls in the file (lines 279 to 388).

Not caused by #1895 or the PRs it was opened beside; found while working on #1866.

Activity

  1. devswha commented on Oct 25, 2026

    @devswha
    OwnerAuthor

    Seen again on the first CI run of two unrelated PRs (1515 ms and 1517 ms against the 1000 ms budget), passing on rerun: #1930 job 121219542941, #1858 job 121225515154.

  2. devswha commented on Oct 26, 2026

    @devswha
    OwnerAuthor

    This test has failed twice today on GitHub-hosted runners (ubuntu-24.04), which are in use while the self-hosted P620 runners are off:

    The test is "text no one wrote by hand > looks once for what closes a bracket, an inline formula or an underscore" (src/lib/markdown.test.ts:248, within(1000, …)). The #1956 failure passed on a re-run. The 1000 ms wall-clock budget is too tight for these runners. An operation count, or a budget relative to a calibration run, would hold on any runner.

  3. added a commit that references this issue on Oct 26, 2026
    4d2e360
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions