GitShow/vercel/otel
vercel

otel

OTEL tracing for Vercel

by vercel
Star on GitHubForkWebsitenpm

TypeScript

97 stars22 forks18 contributorsActive · 10h agoSince 2023@vercel/otel@1.14.2

Meet the team

See all 18 on GitHub →
jankaifer
jankaifer58 contributions
dvoytenko
dvoytenko49 contributions
github-actions[bot]Bot
github-actions[bot]35 contributions
kakadiadarpan
kakadiadarpan12 contributions
gaspar09
gaspar096 contributions
agadzik
agadzik5 contributions
bripkens
bripkens1 contribution
bengigone
bengigone1 contribution

Languages

View on GitHub →
TypeScript96.5%
JavaScript3%
CSS0.4%
HTML0.1%

Commit activity

Last 12 weeks · 6 commits

Full graph →

Community health

1 of 6 standards met

Community profile →
37
✓README○License○Contributing○Code of Conduct○Issue Template○PR Template

Recent PRs & issues

Active · Last activity 10h ago
See all on GitHub →
kakadiadarpan
feat(otel): attach spans to platform tracesOpenPR

Problem Application spans require framework-specific inbound extraction to join Vercel platform traces. Solution Decorate Node context managers to lazily expose the span as parent. Preserve active spans, custom managers, explicit extraction, sampling, and async isolation. Validate with 51 tests, type-check, lint, bundle limits, and a live Node 24 trace. Trace: https://vercel.com/uncurated-tests/node-context-propagation-probe/logs/traces/12e024b6b40e74cb0bef39bb0a74c81d?view=waterfall Related PR(s) https://github.com/vercel/functions/pull/3496 https://github.com/vercel/otel/pull/163

kakadiadarpan · 10h ago
lucleray
fix(otel): strict per-trace span payloads with opt-in mid-run streamingOpenPR

What this is Variation of #214 that structures the exporter for streaming spans during the invocation, while keeping the reliable end-of-trace delivery as the default. Same foundation (per-trace context capture, in-context queue drain, retain-instead-of-drop), plus strict per-trace payload discipline and an opt-in streaming mode. Behavior Default (accumulate): spans of registered traces buffer per trace and ship in one payload at the trace's final flush, through the context captured at root-span start. Untracked traces ship immediately via the ambient context. Unattributable spans are retained and retried instead of silently acked. Streaming (): every flush ships each trace's spans as their own single-trace payload immediately, bounding client memory on long runs. Opt-in and not recommended yet: parts of the platform-side delivery pipeline currently only reliably persist batches delivered near the end of the request, so streamed spans of long traces can still be lost. Once that is addressed, flipping the flag gives streaming without loss; the client side is ready. Both modes: traces never share a payload, so one stale span can no longer poison other traces' delivery (this mixing is what made earlier mid-run shipping attempts non-deterministic). Verification Long-running workflow reproduction, default env: Default (accumulate) mode: all step spans consistently survive across repeated runs (previously only the last few seconds' spans did). Streaming mode on today's platform loses early spans (expected, see above), which is why it is flag-gated. Relationship to #213 / #214 #214: same foundation; this PR supersedes it if we want the streaming option and the strict per-trace payload hardening (or #214 lands first and this rebases to a small delta). #213: kept its in-context flush driver and retain-instead-of-drop ideas. Testing 12 unit tests: default-mode accumulate + finalize semantics, streaming-mode per-flush shipping, strict no-mixing, ambient shipping for untracked traces, no-channel buffering + retry, failing-channel retention, in-context drain triggers, registration lifecycle. , , full unit suite pass. Bundle size limits bumped slightly (main was within ~2KB / ~100 bytes of them).

lucleray · 1mo ago
lucleray
fix(otel): ship each trace's spans in one report through its owning request contextOpenPR

Problem Traces from long-running invocations (e.g. Vercel Workflows) are missing most spans from the first part of the run: the trace looks blank early on, with all step spans bunched into the last few seconds. The work happens the whole time; the spans are genuinely lost. Root cause (client side) 1. The schedules flushes with a bare , which runs outside the request's . The runtime exporter then resolves no request context and silently acked + dropped every mid-run batch. Only the final flush, triggered via (in-context), survived. 2. The queue is shared by all concurrent requests on an instance, so a flush ships other invocations' spans through the wrong request's telemetry channel, where they are not reliably persisted. Fix Capture the owning request context per trace id at root-span start (always in-request), bounded against never-ending traces. The exporter accumulates spans of registered traces per trace and ships the whole buffer in a single report when the trace is finalized from its own request's . Untracked traces keep shipping immediately through the ambient context. Spans that cannot be attributed are retained and re-attempted instead of silently acked. The processor drains the queue in-context on span end (debounced on / ) so long runs cannot overflow . Off-Vercel behavior is unchanged. Verified on a long-running workflow reproduction: with this change all step spans consistently survive across repeated runs (previously only the last few seconds' spans did). Relationship to #213 Same problem; this PR keeps its in-context flush and retain-instead-of-drop ideas, and adds per-trace attribution + single-report delivery, which testing showed is required for reliability on warm instances. Testing Unit tests for accumulation/finalize semantics, per-trace separation, retain/re-ship paths, in-context drain triggers, and registration lifecycle. , , full unit suite pass. Bundle size limits bumped slightly (main was within ~2KB / ~100 bytes of them).

lucleray · 1mo ago

Recent fixes

View closed PRs →
kakadiadarpan
chore: use Node 24 for v1 release (fix OIDC publish E404)MergedPR

Problem The v1.x workflow fails at publish with: is npm's masked response for an unauthenticated publish. ( was never published — is still at .) Root cause Releases use OIDC trusted publishing (no ). detects OIDC but defers the actual OIDC→registry-token exchange to the npm CLI, which requires npm ≥ 11.5.1. v1.x pinned , and every Node 22 release bundles npm 10.9.x (< 11.5.1) → npm can't perform the OIDC exchange → publishes anonymously → E404. The release workflow is identical (same , same OIDC path, same ) and publishes fine — because it runs Node 24 (npm 11.6.2+). That passing run isolates the Node/npm version as the only material difference. The pin likely came from misreading npm's "requires Node.js ≥ 22.14.0" (npm 11.5.1 runs on Node ≥22.14; Node 22.14 does not ship npm 11.5.1). Fix Bump both release jobs to (npm 11.6.2+). Can't use here — that's (Node 18, the v1 SDK's runtime target); the publish job's Node is just tooling and is independent of the package's supported runtimes.

kakadiadarpan · 1mo ago
kakadiadarpan
chore: update v1 changesetsMergedPR

Problem v1 release still uses older Changesets packages/action. v1 trusted publishing is failing after version PR merge. Solution Update and to latest. Pin release workflow to latest tag. Regenerate lockfile. Related PR(s) #208 #209 #210

kakadiadarpan · 1mo ago
kakadiadarpan
chore: fix v1 release pnpm setupMergedPR

Problem v1 release workflow fails in . Workflow set while pins . Pushing to should not trigger a release automatically. Solution Remove explicit pnpm action version. Keep package manager pinned to . Keep release jobs on Node 22. Keep releases manual-only via . Related PR(s) #208

kakadiadarpan · 1mo ago
Structured data for AI agents

Repository: vercel/otel. Description: OTEL tracing for Vercel Stars: 97, Forks: 22. Primary language: TypeScript. Languages: TypeScript (96.5%), JavaScript (3%), CSS (0.4%), HTML (0.1%). Homepage: https://vercel.com/docs/observability/otel-overview Latest release: @vercel/otel@1.14.2 (1mo ago). Open PRs: 15, open issues: 36. Last activity: 10h ago. Community health: 37%. Top contributors: jankaifer, dvoytenko, github-actions[bot], kakadiadarpan, gaspar09, agadzik, bripkens, bengigone, ethshea, huozhi and others.

·@ofershap

Replace github.com with gitshow.dev