Upstash Workflow SDK lets one run carry several labels, with filters matching any of them

Upstash's TypeScript Workflow SDK, workflow-js, now lets a single workflow run carry more than one label, according to the company's changelog. The entry is filed under June 2026 and gives no day or version number.

Per the changelog, the label option on client.trigger and context.invoke accepts either a single string or an array of strings. Filters for run logs, the dead-letter queue and cancellations also accept an array, and they match runs that have any of the given labels, which Upstash describes as OR semantics. Workflow run logs now expose a labels field holding a list of strings. Inside a workflow, context.labels replaces context.label, which Upstash marks as deprecated.

What is new is the plural. Upstash says labels first arrived in September 2025, when they could be used to filter logs and the dead-letter queue by a user-supplied value. Teams that tag runs by, say, customer, feature and environment can now attach all of those to one run instead of packing them into a single string. That use is our reading of the change, not something the changelog describes.

The same changelog page lists a separate, earlier change under March 2026. An optional workflowRunId parameter on notify turns on what Upstash calls lookback: notifications sent before a workflow reaches waitForEvent are stored and delivered anyway, which the company says prevents race conditions. That change is not part of the label release.

What is confirmed is limited to what the changelog says. This is a single-source story: the only credible source we found is Upstash's own changelog, and we located no independent confirmation or testing. Third-party aggregators repeat the same wording and add nothing independent. The page does not say which package version contains each change, whether context.label will eventually be removed, or whether array labels have limits on count or length. Anyone upgrading should check the package release notes and the SDK reference before changing code that reads context.label.

It matters mainly for teams running many workflows in production, where filtering logs and failed runs is a primary way to find a problem. Matching on any of several labels makes broader queries possible, though the changelog offers no usage figures or examples. Treat the behavior described here as the vendor's account of its own software.

Revised 16 October 2026: Guth re-read the original sources and rewrote this article. Correction: the earlier version described multi-label support and the notify workflowRunId option as one recent update. The source lists them as separate changelog entries, June 2026 for labels and March 2026 for workflowRunId. The earlier version remains available as revision 1.