Stale '@listen() CrewAI version mismatch' test stub hides zero coverage on discovery_inquiry_flow (execution_activation_flow has a real, different bug)

[garvitkaushik-123]

Summary

Every test file that touches ad_seller.flows (dozens of them) carries this boilerplate, first introduced in 530df34 (March 2026):

# Stub broken flow modules (pre-existing @listen() bugs with CrewAI version mismatch)
_broken_flows = [
    "ad_seller.flows.discovery_inquiry_flow",
    "ad_seller.flows.execution_activation_flow",
]

It replaces both modules with fake empty classes before any test runs. I went looking for something else and ran into this, then actually tried running both flows for real instead of trusting the comment. The two modules aren't in the same shape — I want to report them separately rather than as one blob.

Part 1 — discovery_inquiry_flow.py: the stated reason is stale

At 530df34, crewai was pinned at >=0.86.0 (pre-1.0). It's >=1.14.4,<2.0.0 now (resolves to 1.15.2) — a major version bump, the kind that plausibly broke and later fixed a decorator API like @listen(). So I tested it directly rather than guessing:

• DiscoveryInquiryFlow().kickoff_async(...) completes cleanly across all four routing branches (default/catalog, "price"→pricing, "available"→availability, "target"→targeting) — every listener finishes, state.status == COMPLETED every time.
• Verified both as a standalone script and under pytest itself (the actual context the stub is guarding), with a minimal isolated test file — no framework error anywhere.
• Also isolated the specific or_() combinator pattern execution_activation_flow.py uses (see Part 2) in a bare-bones Flow against this same pinned crewai version — works correctly.

None of that reproduces a @listen() bug. As a direct consequence, grep -rl "DiscoveryInquiryFlow" tests/ returns nothing — the stub means no test file has ever exercised this module's real code, so nobody would notice either way. 295 lines of production flow logic with zero coverage.

Part 2 — execution_activation_flow.py: a real bug, just not this one

This one does crash for me, but not from @listen(). Running ExecutionActivationFlow().kickoff_async(...) (deal_id path, no live ad server configured) blows up with:

Task exception was never retrieved
future: <Task finished name='Task-7' ...> exception=RuntimeError('Attempted to exit cancel scope in a different task than it was entered in')>

...originating from mcp/client/streamable_http.py's cleanup path when UnifiedClient's OpenDirect MCP session fails to connect/initialize. The interesting part: the code already knows about a related class of problem — execution_activation_flow.py:91-96 wraps the call specifically "to prevent httpcore/anyio CancelScope from leaking into the parent flow listener task" and catches Exception around it:

try:
    await asyncio.create_task(self._od_create_execution_order())
except Exception as e:
    self.state.warnings.append(f"Execution order creation failed: {e}")

The crash I hit is a detached task exception ("Task exception was never retrieved") that never reaches that try/except at all, so the existing defense doesn't catch it and the whole kickoff_async() blows up instead of degrading to a warning the way the code clearly intends.

I don't know yet whether this only happens when the ad server connection fails outright (my test environment has none configured) or whether it can also surface against a real, reachable FreeWheel/GAM endpoint under some error condition — I haven't had a live ad server to test the success path against. So I can't tell you yet whether this is production-relevant or a test-environment artifact, and I'd rather say that plainly than guess.

What I'm asking

1. Can someone confirm whether the @listen()/CrewAI-version story is still accurate, or whether it's safe to drop the stub for discovery_inquiry_flow at least and let it get real test coverage?
2. For execution_activation_flow, is the cancel-scope leak something you've already seen, or worth a closer look as its own thing?

@atc964 — I'd like to take this one up if that's alright: drop the stale stub for discovery_inquiry_flow across the test files, add real coverage for it, and dig into the cancel-scope leak on execution_activation_flow separately (probably as two commits/PRs given they're different problems). Happy to hold off starting until you've had a chance to weigh in on whether the @listen() story checks out on your end too.

Environment

seller-agent main @ d55896e, crewai 1.15.2, 2026-08-18.

[jaanijuk]

Two v2.4.2 observations (e5b367d) that may help scope this.

For context, d55896e is the immediate parent of the v2.4.2 release commit. The release diff touches six files, none under flows/ or the API routers, so the relevant flow and router source is unchanged from the tree you tested against.

Part 1 has a served-endpoint impact. DiscoveryInquiryFlow isn't dormant code: products.py:201 (POST /discovery) imports and instantiates it to process the request. So dropping the stub wouldn't only restore coverage for an internal flow, it would restore it for a served API path. Taken with your reproductions showing the flow completing cleanly under CrewAI 1.15.2, that makes the blanket stub a larger gap than the comment suggests.

Part 2 appears unreachable from an in-repository interface today. A repo-wide search of Python sources for ExecutionActivationFlow finds no invocation outside src/ad_seller/flows/ - no router, MCP tool, or CLI entry point. That's a static check and wouldn't catch dynamic dispatch, but on that evidence the cancel-scope problem reads as a latent integration defect rather than behaviour reachable through an in-repo interface in this release. Still worth fixing before something wires it up, since as you note the failure lands outside the existing try/except and bypasses the intended warning-and-degrade path.

[garvitkaushik-123]

Verified both independently — you're right on both counts.

Part 1: confirmed products.py:201 (POST /discovery) imports and instantiates DiscoveryInquiryFlow at line 225 to actually process the request. I hadn't traced that far — my repro only showed the flow works in isolation, not that it's live-serving traffic. That's a meaningfully different finding than what I filed: this isn't "295 lines of dormant code with no coverage," it's a buyer-facing endpoint that's been running untested since whenever the stub started outliving its reason. Good catch, and it raises the priority on my end — I'll get to this one first.

Part 2: confirmed too — grepped for ExecutionActivationFlow outside flows/ myself and got the same empty result. Agreed it reads as latent rather than live, and agreed it's still worth closing given the failure mode: the code visibly intends to degrade to a warning (execution_activation_flow.py:91-96) and the cancel-scope leak sidesteps that entirely as a detached-task exception. Latent bugs like that have a way of becoming live the moment someone wires up the missing router/MCP tool, at which point it fails in a much less graceful way than the author clearly planned for.

Also appreciate you checking the v2.4.2 diff before commenting — good to have it confirmed that d55896e -> e5b367d didn't touch flows/ or the routers, so nothing here needs re-testing against the release.

Still holding off on starting per my note to @atc964 above, mainly to get their read on whether the @listen()/CrewAI-version story matches what they remember from when the stub went in — but given the served-endpoint angle you've dug up, I'm inclined to move on Part 1 soon regardless. Will split the two into separate PRs as planned.

[atc964]

Confirmed on the history: the stub dates to the March commit you found, and the rationale it cites (CrewAI version incompatibility in the @listen() paths) was true at the time and simply never revisited as CrewAI moved forward. Your two-part read matches our verification, including that DiscoveryInquiryFlow backs the live POST /discovery endpoint, which makes Part 1 the priority. Green light on the two-PR split as you proposed: Part 1 un-stubs DiscoveryInquiryFlow and restores real coverage; Part 2 addresses the ExecutionActivationFlow cancel-scope failure separately. On our side we are also adding per-module coverage reporting to CI so a suite-wide stub can never hide a zero-coverage module behind a green total again. Thanks to you both for the careful verification work.