bug: runs.subscribeToBatch, runs.subscribeToRun sometimes throwing zod schema validation errors

[argjent-serus]

Provide environment information

System:
OS: macOS 26.3.1
CPU: (12) arm64 Apple M4 Pro
Memory: 1.69 GB / 24.00 GB
Shell: 5.9 - /bin/zsh
Binaries:
Node: 22.13.0 - /Users/argjentsahiti/.nvm/versions/node/v22.13.0/bin/node
npm: 10.9.2 - /Users/argjentsahiti/.nvm/versions/node/v22.13.0/bin/npm
pnpm: 9.15.0 - /Users/argjentsahiti/.nvm/versions/node/v22.13.0/bin/pnpm
bun: 1.2.19 - /Users/argjentsahiti/.bun/bin/bun

Describe the bug

When using runs.subscribeToRun, and more frequently runs.subscribeToBatch, the SDK sometimes throws the following parsing error:

Error: Unable to parse shape: [
  {
    "code": "invalid_type",
    "expected": "string",
    "received": "undefined",
    "path": [
      "taskIdentifier"
    ],
    "message": "Required"
  },
  {
    "code": "invalid_type",
    "expected": "string",
    "received": "undefined",
    "path": [
      "friendlyId"
    ],
    "message": "Required"
  },
  {
    "code": "invalid_type",
    "expected": "string",
    "received": "undefined",
    "path": [
      "createdAt"
    ],
    "message": "Required"
  }
]

The issue happens intermittently, but we have seen it occur across development, staging, and production environments.
We do not currently have reliable reproduction steps because the issue only happens sometimes. It appears to be intermittent and does not occur consistently for every run or batch.

Example run IDs where this occurred:

• run_cmolulohwagg00hmvhd9k8vw9
• run_cmoloagju75he0imxokkf9yyn

Reproduction repo

.

To reproduce

I’m not sure how to reproduce this consistently because the issue only happens sometimes. I haven’t found a reliable pattern yet. It appears to be intermittent, and I’m reporting it because I’ve seen it happen more than once.

Additional information

No response

[Prateet-Github]

Hi! I’d like to take a look at this.

Since the issue is intermittent, I’ll start by tracing where the subscription payload is emitted and checking if partial data is being streamed before all required fields are populated.

it might be related to timing/race conditions during run initialization, but I’ll try to confirm and report back with findings.