hamza.khyari
cd9cb9e889
CI / build (pull_request) Successful in 15s
CI / helm (pull_request) Successful in 22s
CI / lint (pull_request) Successful in 3m19s
CI / quality (pull_request) Successful in 3m54s
CI / typecheck (pull_request) Successful in 3m57s
CI / security (pull_request) Successful in 4m27s
CI / integration_tests (pull_request) Successful in 7m1s
CI / unit_tests (pull_request) Successful in 7m44s
CI / docker (pull_request) Successful in 1m31s
CI / coverage (pull_request) Successful in 12m18s
CI / e2e_tests (pull_request) Successful in 21m52s
CI / status-check (pull_request) Successful in 1s
CI / benchmark-publish (pull_request) Has been skipped
CI / benchmark-regression (pull_request) Successful in 54m34s
Thread plan_env and project_env through the tool execution chain so the ExecutionEnvironmentResolver receives project-level execution environment values stored in ContextConfig.execution_environment. The resolver's precedence logic (tool > plan > project > default) was already correct, but callers never passed project_env — tools always fell through to the global HOST default, ignoring project-level overrides entirely. Changes: - PlanExecutionContext: add plan_env and project_env fields + properties - ToolCallRouter: accept plan_env/project_env in constructor, pass to runner.execute() in route() and route_streaming() - ToolCallingRuntime: accept plan_env/project_env, pass to runner.execute() in the direct-runner fallback path - Update monkey-patched execute stubs in tool_router_steps.py to accept explicit plan_env/project_env keyword arguments - Add 4 BDD scenarios proving plan_env/project_env reach the resolver via ToolCallRouter (project-only, plan-only, both, neither) Dependency: requires PR #1135 to be merged first (adds CLI flag and persistence for project-level execution-env-priority). Closes #1080 ISSUES CLOSED: #1080
38 lines
1.9 KiB
Gherkin
38 lines
1.9 KiB
Gherkin
Feature: Execution environment project-level override reaches resolver
|
|
Verifies that project_env threaded through ToolCallRouter
|
|
is forwarded to the ExecutionEnvironmentResolver inside
|
|
ToolRunner.execute(), where it is used at precedence level 2.
|
|
|
|
Issue #1080: execution environment resolution does not honour
|
|
project-level override (precedence level 2).
|
|
|
|
Scenario: ToolCallRouter forwards project_env to resolver
|
|
Given ee1080- a tool registry with a registered echo tool
|
|
And ee1080- a tool runner and resolver spy
|
|
And ee1080- a ToolCallRouter with project_env "container"
|
|
When ee1080- I route a tool call through the router
|
|
Then ee1080- the resolver should have received project_env "container"
|
|
|
|
Scenario: ToolCallRouter forwards plan_env to resolver
|
|
Given ee1080- a tool registry with a registered echo tool
|
|
And ee1080- a tool runner and resolver spy
|
|
And ee1080- a ToolCallRouter with plan_env "host"
|
|
When ee1080- I route a tool call through the router
|
|
Then ee1080- the resolver should have received plan_env "host"
|
|
|
|
Scenario: ToolCallRouter forwards both plan_env and project_env
|
|
Given ee1080- a tool registry with a registered echo tool
|
|
And ee1080- a tool runner and resolver spy
|
|
And ee1080- a ToolCallRouter with both plan_env "host" and project_env "container"
|
|
When ee1080- I route a tool call through the router
|
|
Then ee1080- the resolver should have received plan_env "host"
|
|
And ee1080- the resolver should have received project_env "container"
|
|
|
|
Scenario: ToolCallRouter without env params passes None to resolver
|
|
Given ee1080- a tool registry with a registered echo tool
|
|
And ee1080- a tool runner and resolver spy
|
|
And ee1080- a ToolCallRouter without env params
|
|
When ee1080- I route a tool call through the router
|
|
Then ee1080- the resolver should have received plan_env "None"
|
|
And ee1080- the resolver should have received project_env "None"
|