Uh oh!
There was an error while loading. Please reload this page.
feat(core): emit faas.instance span attribute for compute instance identity - #2989
Conversation
🦋 Changeset detectedLatest commit: b18de57 The changes in this PR will be included in the next version bump. This PR includes changesets to release 16 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
📊 Workflow Benchmarkscommit Backend:
📜 Previous results (4)a7d0e72Wed, 29 Jul 2026 16:19:24 GMT · run logs
d1b2338Fri, 17 Jul 2026 21:11:33 GMT · run logs
5e0e611Fri, 17 Jul 2026 19:14:49 GMT · run logs
ad3b139Fri, 17 Jul 2026 18:50:22 GMT · run logs
ℹ️ Metric definitions & methodologyBest/P75/P90/P99 deltas compare against the most recent benchmark run on Metrics — TTFS: time to first step body (in-deployment start() → first step body, deployment clocks) · STSO: step-to-step overhead (gap between consecutive step bodies) · WO: workflow overhead (whole-run time outside step bodies, in-deployment anchored) · SL: stream latency (in-deployment write → read propagation, readAt - writtenAt) · SO: stream overhead (end-to-end write+consume time beyond the modelled generation window) Scenarios — step: one trivial no-op step, no stream; no hooks, so the run stays in turbo mode (in-process fast path) · stream: one streaming step; no hooks, so the run stays in turbo mode (in-process fast path) · hook + stream: registers a hook before one step, which exits turbo mode (dispatch path) · 1020 steps: 1020 trivial sequential steps; STSO is measured between consecutive steps in the given step ranges, and WO is the whole-run overhead outside step bodies · stream latency: parallel reader/writer steps on a dedicated stream; SL is the in-deployment write->read propagation (readAt - writtenAt) · stream overhead (text): writer streams 300 variable-length text token deltas paced at 100/s for 3s (a haiku-size LLM's token throughput) while a parallel reader drains the whole stream; SO is the end-to-end write+consume time beyond the 3s generation window (overhead/backpressure) · stream overhead (structured): same workload as stream overhead (text), but each delta is an AI-SDK-style structured object ({ type: 'text-delta', id, text }) instead of a raw string, so the SO gap vs the text scenario is the added serialization cost 🔴 marks a percentile over its target (within target is left unmarked). Targets (p75/p90/p99, ms) — TTFS 200/300/600 · SL 50/60/125 · SO 250/500/1000 · STSO (1-20) 20/30/60 · STSO (101-120) 30/45/90 · STSO (1001-1020) 40/60/120 All metrics are measured from deployment-side timestamps only. Runs are triggered by an in-deployment route that stamps the anchor ( Cold starts are kept in the numbers on purpose — they are part of real bursty-workload latency. The workbench deployment cold-starts the |
🧪 E2E Test Results✅ All tests passed E2E Test SummarySummary
Details by Category✅ ▲ Vercel Production
✅ 💻 Local Development
✅ 📦 Local Production
✅ 🐘 Local Postgres
✅ 🪟 Windows
✅ 📋 Other
✅ vercel-multi-region
|
ad3b139 to
5e0e611Compare| * (`cinst_<ulid>`, per the `wrun_`/`step_` convention) whose timestamp is the | ||
| * instance's birth time. Stable for the instance's life and shared by every | ||
| * invocation it handles — including the concurrent ones Fluid packs onto it; | ||
| * cold starts mint fresh ids. Emitted as the OTEL `faas.instance` attribute. | ||
| */ | ||
| export const COMPUTE_INSTANCE_ID = `cinst_${ulid()}`; |
There was a problem hiding this comment.
happy to use a different scheme, opted for consistency with what ive seen so far
…entity Synthesize a per-warm-instance id (cinst_<ulid>) once at module load and emit it as the OTEL faas.instance attribute on the flow and step route spans. Vercel exposes no native per-instance id under Fluid compute, so this lets traces distinguish which compute instance handled each request. Purely additive telemetry. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Alex Langenfeld <alex.langenfeld@vercel.com>
Covers the id format and, on the two-invocation warm-handler case, that both invocations report the same id — the module-scope minting contract that makes the attribute identify the instance rather than the invocation. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Alex Langenfeld <alex.langenfeld@vercel.com>
| kind: spanKind, | ||
| attributes: { | ||
| ...Attribute.WorkflowRouteType('flow'), | ||
| ...Attribute.FaasInstance(COMPUTE_INSTANCE_ID), |
There was a problem hiding this comment.
AI Review: This is currently the only runtime use of COMPUTE_INSTANCE_ID, so the value is added to the OTEL flow span but never sent to workflow-server. The companion server change (vercel/workflow-server#635) expects computeInstanceId in step_started frame metadata and says the SDK already sends it; without adding that serialization here or in the event builder, WORKFLOW_EVENT.computeInstanceId and the Workflow O11y dimension will always be empty. Please pass the same ID through the step event metadata, with protocol coverage, or explicitly split and link the SDK wire change that does so.
There was a problem hiding this comment.
that change is in the draft stacked PR #3186
No backport to This commit adds a new telemetry capability — synthesizing a per-warm-instance id and emitting it as a new To override, re-run the Backport to stable workflow manually via |
Summary & Motivation
Add a way to track which compute instance things are happening on, exposed as
faas.instanceon spans since thats the OTEL standard.Test Plan
Added new test coverage