Move TypeScript worker to SDK 1.23.0 / protobufjs 8 and fix kitchen sink

[veeral-patel]

Fixes test-kitchensink (typescript), red on every PR since 2026-08-26.

Important

Depends on temporalio/features#sdkbuild-drop-protobufjs-override, wired up with a temporary replace in go.mod. That branch must merge first; then drop the replace and bump the require normally.

What broke

@temporalio/common@1.23.0 was published 2026-08-26 and imports protobufjs/ext/protojson, which exists only in protobufjs 8. sdkbuild generates the worker package from "@temporalio/client": "^1.22.0" with no lockfile, so it floats straight to 1.23.0. main's last green run was 2026-08-25 20:59Z — nothing in this repo changed.

Three layered failures, each fixed

1. The module can't resolve. sdkbuild/typescript.go sets pnpm.overrides.protobufjs = 7.5.1:

Error: Cannot find module 'protobufjs/ext/protojson'

Fixed upstream by dropping that pin — added in temporalio/features#625 (May 2025) as an explicitly temporary workaround whose cause is gone (protobuf.js#2379 fixed upstream; sdk-typescript#2303 rewrote the code path onto protobufjs 8).

2. With protobufjs 8 present, the payload converter fails.

TypeError: type must be a Type
  at fromJson (protobufjs/ext/protojson.js:865)

protojson.fromJson does type instanceof Type against its own protobufjs copy. Our root builds Types via require("protobufjs/light") in workerlib/kitchensink/protos/root.js; because the prepared build dir is created inside workers/typescript, that resolves by walking up to workers/typescript/node_modules — a different physical copy from the one pnpm links for the SDK. Same version, different class identity.

Declaring protobufjs in MoreDependencies gives the prepared package its own top-level copy, which pnpm links to the same physical directory the SDK resolves. Note bumping our protobufjs to 8 alone doesn't fix this — two copies of 8.8.0 still have distinct Type classes.

3. The Docker paths then broke the other way.

TypeError: root must be an instance of a protobufjs Root

build-worker / build-project pass the exact mise.toml version to prepare-worker, not the caret from package.json — so they were still installing SDK 1.22.0 (protobufjs 7-era) against our now-protobufjs-8 root. Bumping _.sdk.typescript to 1.23.0 makes every path agree: 1.23.0 + protobufjs 8 everywhere. Applied via the sync-sdk:typescript recipe.

4. Long fields then broke inside the Workflow sandbox.

TypeError: n.toNumber is not a function
  at numify (workerlib/kitchensink/proto_help.ts:72)

numify assumed a 64-bit field is either a plain number or a protobufjs Long with toNumber. In the main thread protojson does hand back a real Long, but inside the Workflow sandbox the long library isn't wired up, so the value arrives as a Long-shaped object with no prototype methods. Every workflow task failed and throughput_stress timed out after five minutes — which is what build-worker (typescript) runs as its second smoke test. Hardened to accept bigint, decimal strings, a real Long, and a plain {low, high, unsigned} object.

Changes

• internal/workerctl/build.go — protobufjs in MoreDependencies
• workers/typescript/workerlib/kitchensink/proto_help.ts — numify handles protobufjs 8 long shapes
• mise.toml + workers/typescript/package.json/lockfile — SDK 1.23.0, protobufjs ^8.8.0, protobufjs-cli ^2.7.0
• go.mod/go.sum — temporary replace for the features fix
• workers/go/go.mod/go.sum — the features bump moves three indirect deps forward, which the nested module inherits

This subsumes #457 (the TS 1.23.0 bump), which can be closed if this lands.

Verification

Run locally against the pushed features commit with no local replace, i.e. what CI does:

	before	after
SDK=typescript kitchen sink	40 fail	40/40 pass
SDK=go kitchen sink	pass	pass
ts worker eslint + prettier	pass	pass (0 errors)
ts worker harness tests	pass	10/10 pass
workers/go build + tests	pass	pass
throughput_stress w/ ts worker	5min timeout	completes in 3.8s

CI on this branch now has test-kitchensink (typescript), build-project (typescript), check-worker (typescript) and the whole check-worker matrix green.

I isolated each layer to confirm all four changes are load-bearing: the features fix alone still fails with type must be a Type; features + protobufjs 8 without MoreDependencies also fails; and protobufjs 8 without the SDK bump breaks the Docker paths.

Notes for review

• protobufjs-cli 2.x deprecates the generated I<Name> interfaces in favour of <Name>.$Properties, adding ~55 eslint warnings (not errors). Migrating those call sites is worth a follow-up, deliberately out of scope.

• Ruby image builds were failing on every PR in the repo, so this branch also fixes them:

  E: Failed to fetch .../libc-dev-bin_2.31-13+deb11u14_amd64.deb  404  Not Found
  

  clang pulls in libc6-i386, which Depends on an exact glibc version, so installing it upgrades libc6/libc6-dev/libc-dev-bin to whatever bullseye-security advertises. Some deb.debian.org CDN edges serve an index naming a glibc point release whose .deb is no longer in their pool — so which edge you get decides whether the build works. The same commit had build-project (ruby) pass while build-worker (ruby) failed.

  Things I ruled out by testing: Acquire::Retries doesn't help (a 404 isn't transient); no clang package variant avoids libc6-i386 (checked clang, clang-11, libclang-dev, libclang-11-dev, llvm-11-dev); pinning glibc to the older bullseye/main build would need --allow-downgrades past security fixes.

  Fixed by sourcing that one apt-get from snapshot.debian.org, which serves immutable index/pool pairs so they can never disagree. Installed versions are unchanged (clang 1:11.0-51+nmu5, libprotoc 3.12.4-1+deb11u1) — only the source differs. The timestamp is an ARG for easy bumping. Verified by building the full image locally: all 18 stages pass, including prepare-worker.

• test-omes flaked once on TestThroughputStress/Run_executor_again,_resuming_from_end; it passes locally and on other runs of this branch.