You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
UpstreamClientContract's route regex times out on loaded runners and can eject any PR #426
UpstreamClientContract.ParseRoutes (tests/OpenCode.Sdk.Tools.Tests/Generator/Binding/Support/UpstreamClientContract.cs:129) matches the whole upstream client source with the RouteCall generated regex:
The pattern has matchTimeoutMilliseconds: 1000. Its lazy wildcards (?:: [^=]*?)? and [^\n]*? backtrack across the source, so one matching pass can exceed one second on a loaded runner.
Effect: the failure depends on runner load, not on the change under test, so it can eject any PR from the merge queue. #424 is held until this is fixed, rather than re-enqueued as a retry.
Fix direction: make the match linear. For example, split the client into per-route-call chunks first and match each chunk, or anchor the pattern so [^=]*? and [^\n]*? cannot scan across declarations. Otherwise, size the timeout to the input, with the reason stated. No retry or quarantine.
Correction to the diagnosis above: Generator measured the pattern, and it does not backtrack. RouteCall takes about 1 ms on the real 81 KB client and stays linear at 40× that size. The three failures landed within 0.4 s of each other, which fits a stalled runner exceeding a wall-clock timeout, not an expensive match. The effect stands: the test result depends on runner load. #428 removes the wall-clock timeout from the test-side regexes over fixed input, with the reason in each file, and adds a 40×-size scale row. #427 covers the tool-side sites.
Fixed by #428: the route regexes over trusted input use Timeout.Infinite, and the measurements in #428 rule out backtracking as the cause. Closing; found in the pre-1.0 issue cleanup.
Activity
Blind-Striker commentedon Oct 17, 2026
Correction to the diagnosis above: Generator measured the pattern, and it does not backtrack. RouteCall takes about 1 ms on the real 81 KB client and stays linear at 40× that size. The three failures landed within 0.4 s of each other, which fits a stalled runner exceeding a wall-clock timeout, not an expensive match. The effect stands: the test result depends on runner load. #428 removes the wall-clock timeout from the test-side regexes over fixed input, with the reason in each file, and adds a 40×-size scale row. #427 covers the tool-side sites.
Blind-Striker commentedon Oct 18, 2026
Fixed by #428: the route regexes over trusted input use
Timeout.Infinite, and the measurements in #428 rule out backtracking as the cause. Closing; found in the pre-1.0 issue cleanup.