CedarCopilot wants to merge 2 commits into staging from fix/recent-executions-toolcallcount
Live on prod, no production signal yet
Libra has verdicts on 0 of 2 tracked behaviors on prod; 2 are still being checked. Libra checks hourly for 3 days after each deploy.
get-recent-executions' toolCallCount was computed as a correlated subquery that interpolates a Drizzle column reference (agentExecutions.runId) inside a raw sql fragment used as a select-list expression. The exact same SQL text run directly against Postgres correlates correctly and returns each run's real count , but executed through Drizzle in this context, it silently lost the correlation and returned COUNT(*) over the entire agent_tool_calls table for every row, regardless of which run was actually being counted.debug tool's recentExecutions result reported toolCallCount: 4710515 for all 9 returned executions , a number matching the table's total row count at the time, not any individual run's real count (which should have been 2, 9, 1, 2, 3, and several 0s). That corrupted payload landed directly in the model's context immediately before its final synthesis step, which then produced no usable output for the rest of an otherwise clean (has_error: false) 55-second turn , a plausible trigger for the silent truncation, though not provably the sole cause.GROUP BY over agentToolCalls filtered by the already-selected runIds via inArray, joined back in memory , avoids the Drizzle correlation bug, avoids the join-fan-out the original per-row subquery was written to prevent, and is one query instead of N.psql against production , it returns correct per-run counts (2, 9, 1) when run as raw SQL, confirming the bug is in how Drizzle compiles this specific interpolation pattern, not the underlying data.pnpm --filter @zero/server run types , no new errors.GROUP BY + inArray) against the same 9 run IDs from the incident , returns the correct real per-run counts (2, 2, 9, 2, 1, 3, and 0 for runs with no tool calls) instead of the ~4.7M constant.This PR replaces a faulty correlated tool-call count subquery with one bounded grouped query over the selected execution run IDs, then maps those counts back to each execution.
The implementation appears safe to merge, with a non-blocking regression-test gap around the database query behavior that caused the original incident.
The run-ID relationship, aggregate typing, zero fallback, and bounded query size align with the schema and existing repository patterns; only direct coverage of the new real-query path is missing.
Files Needing Attention: apps/server/src/mastra/skills/account-config/tools/getRecentExecutionsTool.ts
| Filename | Overview |
|---|---|
| apps/server/src/mastra/skills/account-config/tools/getRecentExecutionsTool.ts | Replaces the unreliable correlated count with a bounded grouped query and in-memory lookup; behavior is sound but lacks focused regression coverage. |
### Issue 1
apps/server/src/mastra/skills/account-config/tools/getRecentExecutionsTool.ts:127-134
**Grouped Query Lacks Coverage**
The new grouped Drizzle query is not covered by a focused test that runs it w
Libra has not measured any production surfaces for this change yet.