fix(executor): remove the env keys a runFlow or retry added when it ends - #195
Open
bulatgaleev wants to merge 3 commits into
Open
bulatgaleev wants to merge 3 commits into
bulatgaleev wants to merge 3 commits into
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.
7 of 13 tasks
bulatgaleev
force-pushed
the
upstream-pr/b2-subflow-env-scope
branch
from
October 2, 2026 04:07
eea5aad to
df20b1b
Compare
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.
Summary
Maestro gives a sub-flow its own env scope:
enterEnvScopesaves the env andleaveEnvScopeputs that copy back, so a key the sub-flow added is gone when it returns (GraalJsEngine.kt, aroundrunSubFlowin Orchestra.kt, whichrepeat,retryandrunFlowall go through, at cli-2.10.0). maestro-runner'swithEnvVarsput each key back to the value it had before, and a key that had none was set to an empty string instead of being removed. After arunFlow,retryor sub-flow withenv: {KEY: ...},KEYstayed defined:typeof KEYwas"string",$KEYexpanded to nothing, andrunShellsawKEY=""in its environment.withEnvVarsnow usesapplyScopedEnv, whichrunScript's env already used (#109): a key is restored when it existed and removed when it did not.Type of Change
Changes Made
withEnvVars, whichrunFlow,retryand a sub-flow file's ownenvgo through, returns the restore function ofapplyScopedEnv.pkg/executor/scoped_env_test.go: a key the block added is removed and a key it changed gets its old value back, and arunFlowwhose env setsSCOPEDleavestypeof SCOPEDas"undefined"for the next step. Both tests fail without the change.Related Issues
No existing issue found. #109 (closed) made
runScript's env scoped in the same way.Testing
go test ./pkg/executor/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
After a
runFlowwithenv:, a name the block added is undefined again, sotypeof KEYis"undefined"andrunShellno longer getsKEY.${KEY}still expands to nothing.Stack 3 of 7: #200 → #194 → #195 → #196 → #197 → #198 → #199. Merge in that order. This branch is built on #200 and #194, so it also contains their commits. This PR's own change is the top commit,
df20b1b. Once the PRs below it merge, the rest of the diff disappears, and nothing conflicts. All seven sit onmainatd3f738f(the merge of #185).