tests/api/endpoints/test_walker_executor.py::TestWalkerExecutor::test_execute_direct_execution_walker passes on its own and fails when the tests/api directory is run together.
Repro
# passes
pytest tests/api/endpoints/test_walker_executor.py::TestWalkerExecutor::test_execute_direct_execution_walker -q
# fails
pytest tests/api -q
Failure
> assert result == {"success": True, "data": {"result": "direct_execution"}}
E AssertionError: assert {'result': 'direct_execution'} == {'data': {'re...uccess': True}
tests/api/endpoints/test_walker_executor.py:68: AssertionError
The walker returns the bare payload instead of the {success, data} envelope — so whether the result gets wrapped depends on state left behind by an earlier test in the directory. A response-envelope or registry global set by one test and not restored is the obvious suspect.
Not caused by recent work
Reproduced on unmodified main (3bed558) as well as on the api/database-config-populate-by-name branch — same failure, both. CI does not surface it, which suggests it is ordering- or environment-dependent rather than universal; on this machine it is deterministic for the tests/api run.
Why it is worth fixing rather than ignoring
An order-dependent test is a permanently ambiguous signal: every future full-suite run has one red line that a maintainer has to recognise and dismiss from memory. That is exactly the condition under which a real regression gets waved through.
Found while running the full suite during #37 / #38.
tests/api/endpoints/test_walker_executor.py::TestWalkerExecutor::test_execute_direct_execution_walkerpasses on its own and fails when thetests/apidirectory is run together.Repro
Failure
The walker returns the bare payload instead of the
{success, data}envelope — so whether the result gets wrapped depends on state left behind by an earlier test in the directory. A response-envelope or registry global set by one test and not restored is the obvious suspect.Not caused by recent work
Reproduced on unmodified
main(3bed558) as well as on theapi/database-config-populate-by-namebranch — same failure, both. CI does not surface it, which suggests it is ordering- or environment-dependent rather than universal; on this machine it is deterministic for thetests/apirun.Why it is worth fixing rather than ignoring
An order-dependent test is a permanently ambiguous signal: every future full-suite run has one red line that a maintainer has to recognise and dismiss from memory. That is exactly the condition under which a real regression gets waved through.
Found while running the full suite during #37 / #38.