Repository navigation
fix(automate): concurrent fetch_page calls returned another call's page - #176
Merged
Merged
Conversation
Each engine drives one shared tab (navigate, then read). Two fetches in flight interleaved, so every caller got the last navigated page's text while the status line still named its own URL. Seen live on the hosted relay: three concurrent fetches (Wikipedia, Salesforce, nichedb) all got nichedb's page, and pit.world summaries came out identical. Navigate+read is now one critical section per engine instance. Regression test with a one-tab fake fails without the lock. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
ThreatCrush Security Scan51 finding(s) HIGH/CRITICAL: 2 | MEDIUM: 28 | LOW: 21
…and 1 more. Full results in the Security tab. Snippets are redacted; ThreatCrush never prints matched credential material. |
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.
Bug
The hosted relay (
tronbrowser.dev/mcp/tron) shares one Obscura process, which has one tab, across up to 3 concurrent calls.viaObscuranavigates, then reads. With two fetches in flight, A navigates, B navigates, and A reads B's page. The status line still names A's URL, so the mix-up is invisible.Seen live: three concurrent
fetch_pagecalls (Wikipedia, Salesforce, nichedb) all returned nichedb's 2,144-char page. One at a time, each returned its own page (60k, 20k and 2k chars). This broke pit.world's Summarize: three different results got the same summary. It also affects Infernet's /chat web search, which reads 3 pages in parallel through this relay.Fix
exclusive(key, fn)makes navigate + read one critical section per engine instance, keyed by the browser object. Obscura fetches now run one at a time, at about 2.5 s each. The Chromium path takes the same lock per session, but the relay already makes a fresh session per call, so that doesn't serialize anything.Tests
A new regression test uses a one-tab fake Obscura with three concurrent fetches. It fails without the lock (b got c's page) and passes with it. The sdk suite is 53 passed, 1 skipped, and
tscis clean.🤖 Generated with Claude Code