adding app id to spans

[shagun-singh-inkeep]

No description provided.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
agents-api	Ready	Preview, Comment	Mar 19, 2026 9:25pm
agents-docs	Ready	Preview, Comment	Mar 19, 2026 9:25pm
agents-manage-ui	Ready	Preview, Comment	Mar 19, 2026 9:25pm

[changeset-bot]

🦋 Changeset detected

Latest commit: 113ca0d

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 10 packages

Name	Type
@inkeep/agents-api	Patch
@inkeep/agents-manage-ui	Patch
@inkeep/agents-cli	Patch
@inkeep/agents-core	Patch
@inkeep/agents-email	Patch
@inkeep/agents-mcp	Patch
@inkeep/agents-sdk	Patch
@inkeep/agents-work-apps	Patch
@inkeep/ai-sdk-provider	Patch
@inkeep/create-agents	Patch

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

[pullfrog]

TL;DR — Adds the app.id attribute to the active OpenTelemetry span during run API key authentication, making it possible to filter and correlate traces by application.

Key changes

• runAuth.ts — Sets app.id on the active span in both the dev-context and standard auth paths of runApiKeyAuthHandler, gated on reqData.appId being present.

_{Summary ｜ 2 files ｜ 1 commit ｜ base: main ← TI-36}

app.id span attribute in runApiKeyAuthHandler

Before: Traces from the run API had no app.id attribute, making it impossible to filter spans by application.
After: When reqData.appId is present, app.id is set on the active span via trace.getActiveSpan()?.setAttribute(...) in both the dev-context early-return path and the standard auth path.

The attribute is added after authentication succeeds but before next() is called, so downstream middleware and handlers inherit the span context. The dev-context path additionally checks attempt.authResult to avoid attributing spans for unauthenticated dev requests.

agents-api/src/middleware/runAuth.ts

  ^{｜ View workflow run ｜ Triggered by Pullfrog ｜ pullfrog.com ｜ 𝕏}

[pullfrog]

Small, focused change — adds app.id to the active span in the two runApiKeyAuthHandler paths. The naming convention (app.id) matches the existing pattern (tenant.id, agent.id, project.id). One minor inconsistency worth addressing.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ pullfrog.com ｜ 𝕏}

[pullfrog]

The dev-environment guard checks attempt.authResult in addition to reqData.appId, but the production path (line 764) only checks reqData.appId. In the dev fallback branch (line 702–709), when appId is present but auth fails, the span won't get the attribute — even though the request is clearly associated with that app.

Since reqData.appId is the only thing that matters for attributing the span, consider dropping the attempt.authResult check to match the production path:

Suggested change

	if (reqData.appId && attempt.authResult) {
	trace.getActiveSpan()?.setAttribute('app.id', reqData.appId);
	}
	if (reqData.appId) {
	trace.getActiveSpan()?.setAttribute('app.id', reqData.appId);
	}

[pullfrog]

Nit: changelog messages should start with a capitalized action verb per the repo conventions (e.g. "Add app.id to span attributes").

Suggested change

	adding app.id to span attributes
	Add `app.id` to span attributes

[claude]

PR Review Summary

(0) Total Issues | Risk: Low

This PR adds the app.id attribute to OpenTelemetry spans during run API authentication, enabling trace filtering and correlation by application. The implementation is clean, correct, and follows established patterns.

🟢 What's Good

• Correct pattern usage: Uses trace.getActiveSpan()?.setAttribute() consistent with existing telemetry code
• Proper naming: Follows the {resource}.id convention (tenant.id, project.id, agent.id)
• Low cardinality: App IDs are admin-created credentials, not user-generated, so this won't cause cardinality explosion
• No PII exposure: The attribute is an opaque identifier
• Intentional guard logic: The different conditions between dev (&& attempt.authResult) and prod paths are correct — prod throws earlier on null auth, while dev should only attribute spans when real auth succeeded (not dev fallback)

💭 Consider (C) 💭

Inline Comments:

• 💭 Consider: runAuth.ts:713 — Optionally add APP_ID to SPAN_KEYS constants for consistency (though mixed patterns exist in codebase)

---

✅ APPROVE

Summary: Clean, focused observability improvement. The code is correct, follows established patterns, and enables useful trace filtering by app. Ship it! 🚀

Reviewers (3)

Reviewer	Returned	Main Findings	Consider	While You're Here	Inline Comments	Pending Recs	Discarded
pr-review-standards	0	0	0	0	0	0	0
pr-review-sre	0	0	0	0	0	0	0
pr-review-consistency	2	0	0	0	1	0	1
Total	2	0	0	0	1	0	1

Discarded (1)

Location	Issue	Reason Discarded
runAuth.ts:712,764	Inconsistent guard conditions between dev/prod paths	Analyzed and found to be intentional — prod path throws before line 764 if authResult is null, while dev path needs the extra check to avoid attributing spans when using fallback dev context

[claude]

💭 Consider: Add app.id to SPAN_KEYS constants

Issue: The new 'app.id' attribute is defined as a string literal, while the codebase has an established pattern of centralizing span attribute keys in SPAN_KEYS in packages/agents-core/src/constants/otel-attributes.ts.

Why: Centralizing attribute names helps maintain a consistent telemetry schema and makes it easier to audit what attributes are being emitted. However, I note the codebase has some mixed patterns (e.g., chat.ts also uses inline strings like 'user.type'), so this is a suggestion rather than a requirement.

Fix: Optionally add to otel-attributes.ts:

APP_ID: 'app.id',

Then import and use SPAN_KEYS.APP_ID here.

Refs:

• otel-attributes.ts — existing SPAN_KEYS definitions