Fix compatibility with Zod 4.4.x

[ziyak97]

I have mentioned this issue here -> #1901

Turns out from release 4.4.0, Zod now treats a property whose schema is z.undefined() as required.

To fix this I have explicitly made them optional.

Ref -> Required object properties with z.undefined() in -> #1901

[changeset-bot]

⚠️ No Changeset found

Latest commit: fe5d16a

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[vercel]

@ziyak97 is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[TooTallNate]

Seems like this was a bug introduced in Zod v4.4.0, but was fixed upstream in v4.4.2, so I don't think implementing the workaround in this repo is necessary. Thank you for bringing this up anyways though.

[ziyak97]

@TooTallNate

This was a bug introduced in Zod v4.4.0, but was fixed upstream in v4.4.2 -> this is not true.

I have updated to v4.4.2 and still get this issue.

The bug is on Workflows side.

Kets like -> error: z.undefined().optional() -> are not just expected to be undefined, they are not expected to exist in the first place. Prior to v4.4.0, this behavior was allowed on Zods side (a bug on their part), but fixed from v4.4.2 onwards.

I think you have referenced a similar thread I had seen earlier, but they have since clarified that this is an expected breaking change from v4.4.x onwards.

Sharing a ref to the - colinhacks/zod#5917 (comment)

Almost every single one of my workflows are failing due to this (I tried on Zod v4.4.2 as well)

[TooTallNate]

Ok thanks for clarifying. I've re-opened and we will confirm the issue you're describing.

[TooTallNate]

Verified the bug and the fix empirically. The Zod 4.4 regression is real (confirmed against zod@4.4.3, latest published) and the issue at colinhacks/zod#5917 captures the upstream behavior change for .optional() interactions with other primitives — it's marked bug and Closed, but the in-the-wild compatibility hazard is here regardless.

The repo's workspace pin is zod: 4.3.6, but zod is a peerDependencies of @workflow/world (and the catalog version is the floor), so consumer apps can — and do — resolve the SDK against any 4.x. A user on 5.0.0-beta-4 with their own zod@4.4.2 resolution hits the bug as soon as the SDK tries to deserialize a wire payload for a non-terminal run.

Verified the fix doesn't compromise validation: z.undefined().optional() accepts both missing properties and explicit-undefined, but still rejects properties with non-undefined values:

missing output:    true
explicit undefined: true
with output value: false   ← still rejected ✓

So the loosening is purely along the "must be explicitly set to undefined" axis — which no real wire producer was doing — and the variant discriminator remains intact.

Comprehensive: this is the only file in the codebase using z.undefined() (grep -rn "z\.undefined\(\)" packages --include="*.ts" confirms). All seven occurrences are in runs.ts and all seven are fixed.

One follow-up suggestion (non-blocking)

The repo's pnpm-workspace.yaml pins zod: 4.3.6, which means CI will continue to build/test against the version that doesn't have this regression — so this fix is unverified in CI. Worth bumping the catalog to 4.4.3 (or ^4.4.0) in a follow-up so future regressions in this class show up locally instead of in user reports. Adding a small runs.test.ts that asserts the schema accepts { status: 'running' } without output/error/completedAt would also be a cheap regression gate.

Thanks for the investigation work in #1901 — clear repro, root-caused, upstream issue linked. Easy approve.

[TooTallNate]

Thanks for the fix — the change is good to merge, but there's one merge blocker: this repo requires verified signatures on commits, and your commits here are currently unsigned (verified: false).

The easiest setup is SSH signing — uses the same key you already have on GitHub for git push:

# One-time global config
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub  # path to the pubkey GitHub knows
git config --global commit.gpgsign true

You also need to register that key as a signing key (separate from the auth key) at https://github.com/settings/ssh/new — choose "Signing Key" as the type. (If you only have one SSH key already configured for auth, GitHub lets the same public key be registered under both types.)

Then on this branch, re-sign your existing two commits:

git rebase --exec 'git commit --amend --no-edit -S' main
git push --force-with-lease

Full GitHub docs: https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification

If you'd rather not deal with the signing setup, let me know and I can re-author the patch on a signed branch with credit to you in the commit message.

[ziyak97]

Thanks @TooTallNate i have signed the commit

[TooTallNate]

Apologies — I should have flagged DCO upfront when you first asked about the signing failure. The two checks share the word "sign" but are independent, and I only mentioned cryptographic signing in my earlier comment. That left you to bounce off DCO as a second hurdle, which is on me.

The signing fix worked — your commit is now verified: true. The remaining DCO failure is a separate check: it requires every commit to include a Signed-off-by: trailer in the commit message body (this is the Developer Certificate of Origin, distinct from cryptographic signing).

The DCO bot provides a fix that doesn't require another rebase. Just add a normal commit with this exact message body:

git commit --allow-empty -m "DCO Remediation Commit for Ziyak <ziyak97@gmail.com>" \
  -m "I, Ziyak <ziyak97@gmail.com>, hereby add my Signed-off-by to this commit: 2bf58718e66abcb8dc66d03d4de6bbbcf5bb1f67" \
  -m "Signed-off-by: Ziyak <ziyak97@gmail.com>" \
  -s
git push

Note the -s flag at the end — that adds the Signed-off-by: trailer automatically based on your git config user.name / user.email (which you've already configured for signing).

Going forward, you can use git commit -s (instead of plain git commit) on every commit and the trailer will be added automatically. Or set it as the default with:

git config --global format.signoff true

After the remediation commit is pushed, the DCO check should turn green and this will be ready to merge.

[ziyak97]

Done @TooTallNate

[TooTallNate]

Merged, thank you @ziyak97 and sorry for the logistical back and forth.

[pranaygp]

@TooTallNate does this need to be backported to 4.x?

[github-actions]

Backport PR opened against stable: #1938. Merge conflicts were resolved by AI — please review carefully.