Edit Issue - .issue.db

Title *

Description

EARS SPEC:
- Every test in tests/ shall be capable of passing against correct behaviour; an assertion that can never be True shall be treated as a defect in the test, not a finding about the code.
- When a workflow completes, the reported workflow result shall come from the workflow's FINAL task, not from an intermediate branch task.
- Stale test expectations shall be corrected DELIBERATELY with the new behaviour justified - never quietly updated to match observed output.

CONTEXT: found during the #850 dependency upgrade. Full suite on the post-#850/#851/#852 stack:
  8 failed, 551 passed, 10 skipped, 1 xpassed in 1244.27s (20:44)
All 8 are DETERMINISTIC (re-ran the fast subset: same 4 failed again, 0 flaky).
All 5 affected test files last changed Feb 2026 (81bb4b4 / a0db1d6) - six months and many engine
releases ago (#825 #826 #833 #836 #843 #845). No test file was modified by #850/#851/#852.

GROUP A - assertions that CAN NEVER PASS (test defects, provably build-independent):
1. tests/unit/test_workflow_run_state_transitions.py::test_update_includes_where_guard
   assert "AND status NOT IN" in update_sql, where update_sql is a psycopg sql.Composed.
   PROVEN in-container:
     "AND status NOT IN" in Composed        -> False   (what the test does)
     "AND status NOT IN" in str(Composed)   -> True
     Composed.as_string(None) contains it   -> True    (the guard IS present)
   Membership on Composed does element-wise EQUALITY against its parts, never substring. So this
   assertion is False no matter what SQL is generated - it cannot go green, therefore it can
   never go red either, and it has been masking whether the guard exists rather than checking it.
   FIX: assert against .as_string(conn) (or str()), not the Composed object.
2. tests/unit/test_workflow_deadline.py::TestDeadlineFailureHandler::test_fail_single_exceeded_workflow
   Same family: compares a call() containing a raw SQL string against a Composed/param call.

GROUP B - workflow result attributed to the wrong task (ENGINE QUESTION, needs a decision):
3. tests/integration/test_switch_operator.py::test_switch_case_matching
4. tests/integration/test_switch_operator.py::test_switch_default_case
   tests/workflow_examples/switch_workflow.py:64  success_task  echoes "Success: Request completed successfully"
   tests/workflow_examples/switch_workflow.py:93  final_report  echoes "Routing completed"
   The test asserts the workflow result is final_report's output; it gets success_task's.
   NOTE the workflow COMPLETED and the step-count assertion PASSED (4 step_succeeded events >= 3),
   so final_report DID run - only the RESULT ATTRIBUTION is wrong. Either the engine should report
   the terminal task's result, or the test's expectation is stale and must be corrected deliberately.
   Same class as #849 (post-release drift in ordering/attribution), not a flake.
5. tests/integration/test_complex_workflow_atomicity.py::test_conditional_branching_true

GROUP C - Docker-in-Docker:
6-8. tests/integration/test_docker_tools.py::test_docker_inspect, ::test_docker_compose_simple,
     ::test_docker_network_isolation
   e.g. compose down returned status "running", expected "stopped" - teardown/timing.

ATTRIBUTION - WHAT IS PROVEN AND WHAT IS NOT:
PROVEN: Group A cannot pass on ANY build (assertion is structurally impossible) - unrelated to #850.
NOT PROVEN: I could not run a dependency baseline (bulkman 2.0.1 / resilient-circuit 0.4.7) to
  demonstrate Groups B and C failed BEFORE the upgrade. The runtime image ships no pip and no uv
  (minimal, compiled-bytecode image), so an in-place downgrade is impossible; a real baseline needs
  a rebuild with the old pins. Mechanically these paths are not reachable from the change - circuit
  breakers are DISABLED ([features] circuit_breaker_enabled = false, verified in-container), and
  bulkman 2.0.1->2.0.3 is pin-widening only - but that is REASONING, not a reproduction. Per the
  standard set in #849, a baseline rebuild should be run before calling these pre-existing.

Priority

Status

Due Date (YYYY-MM-DD)

Tags (comma separated)

Related Issues (IDs)

Enter IDs of issues related to this one. They will be linked as 'related'.

Cancel

Edit Issue #853