[worker-shim] Real-native DeepSeek test can build the first model request before an authored local stdio MCP server is ready

Chiusa
#205 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
typescript

Direzione di ricerca

Read the session-open and turn-start path in packages/worker-shim/src/adapters/deepseek.ts, its native host, and the native runtime's MCP startup behavior. Start by checking whether authored stdio servers expose a readiness signal; then make the test wait for tools/list before starting the Turn, or await runtime readiness if the adapter owns the ordering. Done means the cause is identified and the test no longer depends on startup timing; verify against docs/specs/20260529-test_strategy.md and docs/verification-instruments.md.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug

Problem

The real-native DeepSeek adapter test executes an authored local MCP tool alongside managed MCP without granting it Gateway credentials (packages/worker-shim/src/adapters/deepseek-native.test.ts) failed once on a GitHub-hosted runner because the first model request did not offer the authored local stdio MCP tool.

Observed on commit 7bbd02bfcdd3e993e6fef89b36e7a24ea6a84398 (the #200 test fix):

  • CI run 38059417060, job "L0-L2 static, unit, contract": the test failed after 3481 ms at the assertion on the first synthetic inference request. That request listed 28 tools, including the managed MCP tool mcp__managed__managed_echo, but not the authored local tool mcp__local__local_echo.
  • CI run 38060087148 on the same commit: the whole job passed, including this test.

The authored server is declared in the native home's cordis.patch.yml as a stdio server with failOnStartupError: true, so a startup failure would have failed the Turn. The Turn completed instead, which suggests the local server had not finished initialize and tools/list when the first model request was built. The two tests that #200 targets passed in both runs.

What is not known yet

  • Whether the native DeepSeek runtime waits for authored stdio MCP servers to be ready before its first model request, or whether the adapter starts the Turn before the runtime reports them ready.
  • If neither waits, a real Turn under load can miss an authored local tool on its first model step. The managed MCP path was not affected in this run.

Suggested fix

  1. Read the adapter's session-open and turn-start path (packages/worker-shim/src/adapters/deepseek.ts and the native host it drives) and the native runtime's MCP client startup to find out whether a readiness signal for authored MCP servers exists.
  2. If one exists and the adapter does not await it, await it before the first Turn and add a regression that delays the local server's tools/list response and checks that the first model request still offers the tool. This changes product behavior, so check it against the owning runtime-integration specification first.
  3. If the native runtime offers no readiness signal, treat it as runtime behavior: record it in the adapter's README and make the test wait for the local server's tools/list (for example with a marker file written by the synthetic server) before it starts the Turn, instead of depending on startup winning a race.
  4. Separately from the cause, consider running every real-native DeepSeek test file (deepseek-native, deepseek-harness, deepseek-fault) in the sequential Vitest project that #200 introduced for deepseek.test.ts, so CI load does not stretch native startup.

Acceptance criteria

  • The cause is named: native runtime behavior, adapter ordering, or test setup.
  • The test cannot pass or fail based on whether the local server's startup wins the race with the first model request.
  • L0-L2 static, unit, contract passes on hosted runners without this test as the deciding failure.

References

  • #200 (same family: real-native DeepSeek tests that depend on wall-clock headroom on shared runners).
  • docs/specs/20260529-test_strategy.md, docs/verification-instruments.md.
  • Triage: not a release blocker. A failed L0-L2 job on the exact candidate is rerun; it does not change the tested commit.
Lingua principale
TypeScript
Stelle
0
Fork
1
Merge medio
5h 57m
PR unite (30g)
3

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di lingkaix/openkit

Tutte le issue di lingkaix/openkit

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.