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
tuple[type[PolicyRunner], type[VideoConfig]] + drop line 28 + string forward-refs
FAIL: 6 errors (name-defined)
(would pass, but mypy blocks it)
tuple[type, type] (R4 form) + drop line 28
FAIL: 5 errors (no-any-return, attr-defined on VideoConfig.from_dict)
clean
mypy needs a module-scope name binding to resolve return-type names; CodeQL forbids any module-scope edge (TYPE_CHECKING included) to policy_runner.
Why a CodeQL config suppression is the right answer
The runtime is provably safe under from __future__ import annotations:
All type hints are strings at runtime, never resolved at module-import time.
The _lazy_policy_runner() helper is a function, not module-level code; its body executes only at call time, by which point both modules are fully loaded.
The companion regression tests in tests/simulation/test_no_import_cycle.py pin three AST-level invariants (helper exists, helper is called by all four SimEngine methods, no module-level direct import) and round-trip-verify they fail on pre-fix code.
This is the textbook profile of a documented false-positive for py/unsafe-cyclic-import.
Context
Follow-up tracking issue for the architectural deadlock identified in PR #209 (currently draft, paused per AGENTS.md round budget).
Problem (from PR #209 S13/R6)
In
strands_robots/simulation/{base.py, policy_runner.py, benchmark.py}, mypy and CodeQL have mutually exclusive requirements:tuple[type[PolicyRunner], type[VideoConfig]]+ line-28 TYPE_CHECKING importtuple[type[PolicyRunner], type[VideoConfig]]+ drop line 28 + string forward-refsname-defined)tuple[type, type](R4 form) + drop line 28no-any-return,attr-definedonVideoConfig.from_dict)mypy needs a module-scope name binding to resolve return-type names; CodeQL forbids any module-scope edge (TYPE_CHECKING included) to
policy_runner.Why a CodeQL config suppression is the right answer
The runtime is provably safe under
from __future__ import annotations:_lazy_policy_runner()helper is a function, not module-level code; its body executes only at call time, by which point both modules are fully loaded.tests/simulation/test_no_import_cycle.pypin three AST-level invariants (helper exists, helper is called by all fourSimEnginemethods, no module-level direct import) and round-trip-verify they fail on pre-fix code.This is the textbook profile of a documented false-positive for
py/unsafe-cyclic-import.Proposed approach (Option A in PR #209 S13)
.github/codeql/config.yml(or extend the existing one if any) with a path-scoped suppression:SECURITY.md(or equivalent) documenting the suppression and its rationale.Round budget
1 round expected. The change is small (~20 lines of config + a doc note) and has been pre-justified by the multi-round investigation in PR #209.
Out of scope
policy_runner.pyintobase.py(Option B in PR fix(simulation): defer policy_runner import to break unsafe cyclic-import cycle #209). Defer until/unless Option A is rejected by maintainers.py/unsafe-cyclic-importfor any files outside the simulation triple.References