Repository navigation
fix(jsengine): give a script's http call Maestro's 5 minutes - #196
Merged
omnarayan merged 4 commits intoOct 3, 2026
Merged
Conversation
This was referenced Oct 2, 2026
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
…lls any more 30257df (Android device queries match the whole text and id) took out the last caller of this helper in the uiautomator2 driver. The unused linter has flagged it since, so Lint has failed on every push to main, and Build, which needs Lint, has been skipped each time. The same helper in the appium and devicelab drivers is untouched.
Maestro runs a runScript file as plain JavaScript. It reads the file and
evaluates ${...} only in the step's env, when: condition and label; the
script text goes to the engine as it is (YamlFluentCommand.kt:409-424,
Commands.kt:1029-1035, Orchestra.kt:723-737).
The runner expanded ${...} and $VAR across the whole file before running
it. A template literal that used the script's own variables was replaced
ahead of the script, against variables that did not exist yet:
`/v1/x?email=${encodeURIComponent(who)}&state=${state}` came out as
`/v1/x?email=undefined&state=`.
A script file now runs as written. Inline script text, which Maestro has no
equivalent of, keeps the expansion.
Maestro gives a sub-flow its own env scope: enterEnvScope saves the env and
leaveEnvScope puts that copy back, so a key the sub-flow added is gone when
it returns (GraalJsEngine.kt:223-238, around runSubFlow at
Orchestra.kt:1159-1197, which repeat, retry and runFlow all go through).
The runner's withEnvVars restored each key to the value it had before, and
a key that had none was set to "" rather than removed. After a runFlow,
retry or sub-flow with `env: {KEY: ...}`, KEY stayed defined: typeof KEY was
"string", `$KEY` expanded to nothing, and runShell saw KEY="" in its
environment.
withEnvVars now uses applyScopedEnv, which runScript's env already used:
a key is restored when it existed and removed when it did not.
Maestro builds its script http client with 5-minute read, write and call timeouts (GraalJsEngine.kt:28-34), and the CLI passes no client of its own (Orchestra.kt:138 and 161), so every call gets them. The runner's http.* gave a call 30 s unless the call set `timeout`, so a script that calls a slow endpoint (seeding test data, waiting on a server-side job) failed with "HTTP request failed" where Maestro waits. A local server that answered after 32 s failed the call at 30 s. A call without a timeout option now gets 5 minutes. The option still wins.
7 of 13 tasks
bulatgaleev
force-pushed
the
upstream-pr/b2-script-http-timeout
branch
from
October 2, 2026 04:07
51c0b3e to
33e4e37
Compare
Contributor
|
Thanks @bulatgaleev! Matching Maestro's 5-minute default for |
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
2 participants
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.
Summary
Maestro builds the http client of its script engine with 5-minute read, write and call timeouts (
GraalJsEnginein GraalJsEngine.kt), and the CLI passes no client of its own (Orchestra.kt), so everyhttp.*call from a script gets them (cli-2.10.0). maestro-runner gave a call 30 seconds unless the call settimeout, so a script that calls a slow endpoint, such as one that seeds test data or waits on a server-side job, failed withHTTP request failedwhere Maestro waits. A call without atimeoutoption now gets 5 minutes, and the option still wins.Type of Change
Changes Made
pkg/jsengine/http.go: the default timeout isdefaultHTTPTimeout, 5 minutes. It is a variable so a test can shorten it.pkg/jsengine/http_timeout_test.go: the default is 5 minutes, a call withouttimeoutwaits for the default and times out when the server is slower, and a call with its own longertimeoutstill succeeds.Related Issues
No existing issue found.
Testing
go test ./pkg/jsengine/mainthe call failed at 30 seconds withHTTP request failed ... Client.Timeout exceeded while awaiting headers. With the change it returned status 200.go test -raceforpkg/executor,pkg/driver/wda,pkg/jsengine,pkg/flowandpkg/driver/uiautomator2passes at the top of the stack;go vet ./...,gofmt -land golangci-lint v2.13.2 (the version CI pins) report nothing on every branch of the stackmake testas a whole: not run, because its device tests drive whatever device is attached to the machinemake lint: the Makefile has nolinttarget, and the other lintersmake checkruns (staticcheck, revive, errcheck, nilaway, gosec) are not installed hereChecklist
Additional Notes
A call to a server that never answers now fails after 5 minutes instead of 30 seconds, as it does under Maestro. A script that wants the shorter wait sets
timeouton the call.Stack 4 of 7: #200 → #194 → #195 → #196 → #197 → #198 → #199. Merge in that order. This branch is built on #200, #194 and #195, so it also contains their commits. This PR's own change is the top commit,
33e4e37. Once the PRs below it merge, the rest of the diff disappears, and nothing conflicts. All seven sit onmainatd3f738f(the merge of #185).