Fix create_scenario reporting false failures and storing duplicates - #2
Open
92Infinitus92 wants to merge 2 commits into
Open
Fix create_scenario reporting false failures and storing duplicates#292Infinitus92 wants to merge 2 commits into
92Infinitus92 wants to merge 2 commits into
Conversation
…storing duplicates The MCP tools called HTTP through reqwest's blocking client from async tool functions, so a create_scenario the server had accepted could still be reported as a connection failure; the model retried and stored a duplicate. They now use the async client, and POST /v1/scenarios treats an identical retry as a no-op while rejecting different content under a taken id with 409.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The MCP tools ran HTTP through reqwest's blocking client from async tool functions.
A
create_scenariothe server had already stored (POST /v1/scenarios 200in theCLI log) could still be reported to the model as a connection failure — it retried,
and a second scenario landed under the same id, so the studio showed two identical
cards. All three affected tools now use the async client.
POST /v1/scenariosis idempotent by content: same id and same document is ano-op, different content under a taken id returns 409. The check shares the write
lock with the insert, and
create_scenarioturns a 409 into an actionable message.The template-registry read guard moved into its own scope — holding it across the
new await made the future non-Send.
Testing. cargo test: cli 20/20 (new test: create → identical retry →
conflicting content), mcp 5/5, core pyth 3/3; fmt clean. Live with Claude and
OpenAI: three scenarios in a row, one POST each, no retries, clean logs.
Not addressed here: MCP failures still come back as successful tool results
carrying an error payload — fixing that means honouring
isErrorin the sharedclient path used by all five providers, a separate change.
Greptile Summary
The PR makes scenario creation idempotent and migrates MCP HTTP operations from blocking to asynchronous reqwest calls.
Confidence Score: 5/5
The PR appears safe to merge.
No blocking failure remains.
Important Files Changed
Sequence Diagram
sequenceDiagram participant MCP as MCP create_scenario participant API as POST /v1/scenarios participant Store as Scenario store MCP->>API: POST scenario API->>Store: Acquire write lock and find ID alt ID absent API->>Store: Insert scenario API-->>MCP: "200 {id}" else Same ID and document API-->>MCP: "200 {id} (no-op)" else Same ID, different document API-->>MCP: 409 conflict MCP-->>MCP: Return actionable error payload endReviews (2): Last reviewed commit: "Merge branch 'feat/pyth-price-feed-field..." | Re-trigger Greptile