Task run events are being strictly validated
A structural loophole in the API client is being closed, replacing loose validation with strict schemas to prevent the SDK from returning invalid task run data formats.
The core API client is getting strict new data validation. Previously, task run events bypassed schema checks entirely, allowing unexpected data formats to slip through and potentially cause errors downstream.
The system now enforces strict validation on all task run events. Developers receive consistent, typed event data, including proper handling for tricky edge cases like 19-digit nanosecond timestamps and root spans with missing parent IDs. Tools integrating with the API receive exactly the data shape they expect, without runtime crashes or type mismatches.
View Original GitHub Description
Resolves the internal TODO in
ApiClient regarding missing schema validation for task run events.
✅ Checklist I have followed every step in the contributing guide The PR title follows the convention. I ran and tested the code works Technical Cost/Benefit Analysis Benefit:
Reliability: Replaces z.any() with a strict Zod schema, preventing the SDK from returning invalid or unexpected data formats. Safety: Addresses two critical edge cases identified during development: Wrapper Handling: The API returns { events: [...] }. This PR adds the
ListRunEventsResponse wrapper. Nullable parentId: Supports null for root spans (stored as null in DB). Integration: Ensures consistency for tools like the MCP server. Cost/Risk:
Low Risk: Localized change to @trigger.dev/core. Highly decoupled from other services. Testing Unit tests in
packages/core/src/v3/schemas/api-type.test.ts verify:
Valid event parsing & date coercion. Failure on invalid data. Handling of null and undefined for parentId. Handling of the { events: [...] } response wrapper. Changelog @trigger.dev/core: Added
RunEvent and
ListRunEventsResponse Zod schemas. @trigger.dev/core: Updated ApiClient.listRunEvents to use strict validation.