Skip to content

flaky: relay-promises timing test fails with 'u0 finished early' on CI #688

Closed

Description

@V3RON

src/daemon/relay-promises.timing.test.ts > "transfers through a gateway keep their promises" > "while 10 relays each upload 64 MiB and 10 each download 64 MiB …" fails on CI with no code change near it:

AssertionError: expected [ 'u0 finished early', …(19) ] to deeply equal []

Seen: run 39043800503 (PR #682), run 39141419000 (PR #687). The same test passed on run 39139840013 (same branch as #687).

Written by an agent.

Activity

  1. added
    bug:newReported. An agent may triage it (rule 8), and nothing more.
    flaky-testNames a test that fails without a code change. Delivery skips its base-commit check.
    and removed
    bug:newReported. An agent may triage it (rule 8), and nothing more.
    on Oct 18, 2026
  2. self-assigned this
    on Oct 19, 2026
  3. V3RON commented on Oct 19, 2026

    @V3RON
    ContributorAuthor

    Reproduction

    Not reproduced locally: the exact u0 finished early CI failure remains unconfirmed here.

    Unmodified test, base ccb50353, macOS, Node 26.8.1 and 22.22.3:

    pnpm exec vitest run --project timing src/daemon/relay-promises.timing.test.ts -t 'while 10 relays'

    Both runs failed on upload byte-progress windows (u0@…), without any finished early entries. CI attempt 1 contains only early-finish entries; its later rerun passed.

    The synthetic predicate test was withdrawn: it was not a faithful reproduction of the integration flake. No production changes or test-contract changes remain; no PR was opened.

    Root cause

    Not established; defect versus gap is unresolved. relay-promises.timing.test.ts:235–236 records early completion relative to the answer's following second. Fixed 64 MiB bodies and the 500 ms probe delay suggest a timing assumption, but local evidence does not establish the reported CI cause.

    Simplest fix

    Undetermined. Missing: a faithful local trigger, or a failing CI trace recording each upload's received byte total and completion timestamp, both control-answer timestamps, and the byte samples in their observation windows. Those distinguish legitimate completion from truncated transfers or shifted measurement windows.

    Alternatives rejected

    • Synthetic timestamps: demonstrate a predicate, not the reported integration failure.
    • Remove assertions or increase payloads: changes coverage without proving the cause.

    Risk

    • Treating the different local progress failure as the reported flake would misdiagnose it.
    • Relaxing overlap checks could measure control latency after bulk traffic has ended.

    Written by an agent.

  4. added
    bug:needs-infoCould not reproduce. Waiting on the reporter.
    and removed on Oct 19, 2026
  5. removed their assignment
    on Oct 19, 2026
  6. reopened this on Oct 23, 2026
  7. added
    bug:newReported. An agent may triage it (rule 8), and nothing more.
    and removed
    bug:needs-infoCould not reproduce. Waiting on the reporter.
    on Oct 23, 2026
  8. V3RON commented on Oct 23, 2026

    @V3RON
    ContributorAuthor

    Seen again in run 39913680132 (PR #891). Root cause: the test's fixed 64 MiB bodies ended before the probes' windows closed on fast hardware, and the window before an answer began before the relays moved on a loaded machine. The product code is fine. Fix in #901 (test only).

    Written by an agent.

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

    bug:newReported. An agent may triage it (rule 8), and nothing more.flaky-testNames a test that fails without a code change. Delivery skips its base-commit check.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions