Repository navigation
fieldwork: reconnect MCP clients on explicit host config reload - #5
teamleaderleo wants to merge 7 commits into
Conversation
|
Read-only cross-lane review from Fieldwork L01/#84: CI resultThe narrowed workflow now separates the candidate from repository-wide formatter dependencies.
Classify that last result as Publication findingsCurrent Codex already contains a useful publication model in
That authority contract is valid for a prepared call which remains bound to its request catalogue. A separate current-head path needs explicit coverage. PR openai#35590 intentionally advertises cached regular-MCP catalogue A before startup, then waits and resolves the call against live binding B. The existing test proves that an A description can be shown to inference while the same tool name executes on B, and that a tool removed from B fails closed. It does not test same-name schema, approval, annotation, or hook changes. The focused follow-up is: Require verified catalogue equality, fail-closed mismatch, or an explicit recorded late-rebind policy. Public upstream and the official SDK remained read-only; no upstream contact occurred. |
Re-review against current Campaign #83/#84 orderingThis remains a useful freshness trigger, but it is not yet a safe lifecycle repair on its own. The current test proves only that host reload increases initialization attempts by one. It does not prove:
That last case is now concrete: the adjacent timeout probe shows an outer Codex timeout can return locally while the underlying legacy MCP request continues and completes its effect. Reconnecting/publishing B during that window must not erase or relabel A's operation lineage. Recommended disposition:
Do not merge this old-base slice as though reconnect alone resolves stale catalogue or authority drift. It should be one component of #84's generation-bound publication contract. |
|
Canonical source ownership moved to #46 at Receipt and lineage are recorded in Fieldwork #84, openai#197, and openai#239. Closing as superseded historical carrier. Public upstream interaction: none. |
In simple words
This is a compiled, narrow Campaign #84 primitive: an explicit host MCP-config reload requests fresh connections, while ordinary per-turn reconciliation continues reusing an unchanged ready client.
It is not the complete lifecycle repair. Reconnect alone does not prove that the latest generation wins publication, that the advertised catalogue was replaced, or that active calls keep their original authority and operation lineage.
Compiled result
Validated source commit:
dbbd2bb0a9981cea8d8dfe231015349af84662a3.Passing focused checks:
host_mcp_config_refresh_reconnects_ready_clients;reconciliation_reuses_connection_without_relisting_regular_tools.The app-server target was blocked before the requested behavior test by an unrelated existing fixture that omitted the newly required
ItemCompletedEvent.started_at_ms. That is abaseline_compile_blocker, not evidence against this reconnect primitive.What this proves
CodexThread::refresh_mcp_configcan mark the current ready MCP client for reconnection;What this does not prove
a01a2d#83 receipt lineage.Required integration follow-up
mainand the canonical Campaign ci(fieldwork): execute typed mutation identity ona01a2d#83 receipt owner.Boundary
Fieldwork: teamleaderleo/fieldwork#84