Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Bug][CI]: web-search pacing deadline test fails on a loaded Windows shard (504 on reset replay)

Closed
  • Is something wrong?
#6,988 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
1-2 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
github-actions, typescript
Domain
testing

Research direction

Start with tests/web-search/web-search-pacing-deadline.test.ts, especially the reset replay case around line 145 and the later started assertion around line 213; inspect the related test added by #6700 and the web-search pacing and deadline code it exercises. Reproduce the failure on a loaded Windows shard, then determine whether the deadline calculation is wrong or the test depends on insufficient timing slack. Done when the test is reliable on loaded Windows runners or a confirmed source defect is fixed.

Written by the indexing model from the issue text.

Description

bug platform tools
Client or integration

Other

GitHub Actions Windows suite shard (windows 8/9, dispatch-only lane), not an installed client.

Area

Tools / MCP / web search

Summary

tests/web-search/web-search-pacing-deadline.test.ts (added by #6700) failed two cases on a Windows shard in a full lane=all dispatch. The failure kind was assertion, so the shard failed on first occurrence as designed.

  • reset replay excludes its own pacing wait expected 200 and received 504 (line 67 via line 145), after the log printed [upstream-retry] connection reset (web-search-loop) — retrying (2/3).
  • A later case in the same file expected started to be 2 and received 1 (line 213).

The test asserts that local pacing waits are excluded from the response-header deadline. A 504 here means the deadline fired on a loaded Windows runner. Either the pacing wait was still counted against the deadline on that path, or the test's deadline leaves too little room for a reset replay under Windows scheduling. Recent dev dispatches failed Windows shards on different timing tests each time (ocx status codexPlugins 20s, retained-sync Ultra Fast 20s, plaintext v2 drip-feed, credential separation, gateway startup), and none of those were in this file, so this is a new case.

Expected: the case either passes on loaded Windows runners because its assertions do not depend on wall-clock slack, or the 504 is shown to be a real pacing/deadline defect and fixed in the source.

Reproduction
  1. Full dispatch https://github.com/lidge-jun/opencodex/actions/runs/38222141865 (branch codex/6978-macos-shard-budget-261012, head 736e7bf04e, which changes only the macOS shard matrix and its contract tests).
  2. Job windows 8/9, batch 45/45, file tests\web-search\web-search-pacing-deadline.test.ts.
Version

736e7bf04e570974c0217b37c7de136c00a03b38 (dev a0191a1b6f + macOS shard matrix change)

Operating system

GitHub-hosted windows-latest

Provider and model

Not applicable (test fixtures).

Logs or error output
[upstream-retry] connection reset (web-search-loop) — retrying (2/3)
error: expect(received).toBe(expected)
Expected: 200
Received: 504
      at expectSuccess (tests\web-search\web-search-pacing-deadline.test.ts:67:27)
      at async <anonymous> (tests\web-search\web-search-pacing-deadline.test.ts:145:13)
(fail) web-search pacing and response-header deadline > reset replay excludes its own pacing wait [483.85ms]
error: expect(received).toBe(expected)
Expected: 2
Received: 1
      at <anonymous> (tests\web-search\web-search-pacing-deadline.test.ts:213:21)
Test failure in shard 8/9 batch 45/45 (exit 1); not retrying assertion/test failures.
Screenshots and supporting files

No response

Redacted configuration

No response

Checks
  • I searched existing issues and documentation.
  • I removed secrets, tokens, account details, request credentials, and personal data.
Dominant language
TypeScript
Stars
16.9k
Forks
1.3k
Avg merge
5h 7m
Merged PRs (30d)
617

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from lidge-jun/opencodex

All issues in lidge-jun/opencodex

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.