Skip to content

Make the Sidekick preview-to-reply journey wait for its published response #1009

Open

Description

@taras

The Sidekick preview-to-reply journey must wait until its canonical response is published before inspecting that response. Seeing the reply text on screen is an earlier moment: the entry carried by that reply can still be evaluating.

At 8aedd193967fa8f568022edc34905d26c4f0b327, PV1: the preview and the reply that replaces it are one item in packages/cli/tests/repl-sidekick-journey.test.ts intermittently reads zero responses after its screen-text wait. The assertion at line 1397 expects one response and receives [].

Evidence:

  • First failing CI job, attempt 1, test-node (5/10), Node 22.23.4 on Ubuntu: 45 of the file's 46 tests pass; PV1 fails. The shard continues through its remaining files.
  • The unchanged revision passes the whole affected file locally under Node 26.5.1, then fails on run 19 of 20 isolated PV1 processes. Instrumenting the real case reproduces it again on run 14. This is evidence of intermittence, not a reason to discard the failure.
  • At the failing moment, the published chat ends with control, control-outcome, control and has no response or feedback. The Transcript already displays [S] Half a thought., while Sidekick still displays the preview, evaluating the reply, and working.

Run the affected file with:

npx tsx --tsconfig tsconfig.node.json --test packages/cli/tests/repl-sidekick-journey.test.ts

The pending repair in PR #1004, commit 4bc489e0df00e5b26f581f1a20ae1604435712e9, adds a bounded operation-based wait for the actual published response. The existing one-response, one-reply and no-preview assertions remain. It changes two test/fixture files, with no production change, deadline increase, test exclusion or unchanged CI rerun.

Focused repair evidence: 40 isolated PV1 runs pass; the full affected file passes under Node 26.5.1 (46/46), Deno 2.9.7 (12 roots/46 steps) and Bun 1.3.14 (46 tests/514 assertions). Required CI on the repaired commit and delivery remain outstanding.

Close this issue only after the cause is fixed and regression and delivery evidence are recorded. A green rerun of the old revision does not close it.

Activity

  1. added
    flakeIntermittent or timing-sensitive failure that can pass without a code change
    on Oct 28, 2026
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

    flakeIntermittent or timing-sensitive failure that can pass without a code change

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions