feat(attributes): Add FaaS/AWS conventions and deprecate Lambda-specific attributes#414
Conversation
…fic attributes Add OTel-aligned attributes for FaaS and AWS Lambda context: - faas.invocation_id, faas.version, aws.lambda.invoked_arn - aws.log.group.names, aws.log.stream.names, cloud.resource_id Deprecate corresponding AWS Lambda-specific attributes in favor of the OTel-aligned equivalents. Refs PY-2307
Semver Impact of This PR🟡 Minor (new features) 📋 Changelog PreviewThis is how your changes will appear in the changelog. New Features ✨
Internal Changes 🔧
🤖 This preview updates automatically when you update the PR. |
| @@ -0,0 +1,16 @@ | |||
| { | |||
| "key": "cloud.resource_id", | |||
There was a problem hiding this comment.
q: What's the difference between this attribute and aws.lambda.invoked_arn?
There was a problem hiding this comment.
as a follow-up:
- If there's no difference, which one should we prefer?
- if there is a difference, can we document it in
additional_context?
There was a problem hiding this comment.
q: What's the difference between this attribute and aws.lambda.invoked_arn?
This attribute is more flexible in that it's meant to represent the identifier of any cloud resource regardless of the provider. It can hold the ARN from AWS (what could also be stored in aws.lambda.invoked_arn if it's referring to an AWS lambda resource), but also represent the full resource name from GCP or fully qualified resource ID on Azure.
From OTEL's docs:
Cloud provider-specific native identifier of the monitored cloud resource.
with these as example values:
arn:aws:lambda:REGION:ACCOUNT_ID:function:my-function; //run.googleapis.com/projects/PROJECT_ID/locations/LOCATION_ID/services/SERVICE_ID; /subscriptions/<SUBSCRIPTION_GUID>/resourceGroups/<RG>/providers/Microsoft.Web/sites/<FUNCAPP>/functions/<FUNC>
as a follow-up:
If there's no difference, which one should we prefer?
if there is a difference, can we document it in additional_context?
On their "AWS lambda" page, they have a note which I'm interpreting as a recommendation to set the faas and cloud attributes alongside them:
Can definitely add a note to the additional_context though to provide some clarity here 👍🏻
…-conventions into py-2307-add-conventions
…/faas pairs Add bidirectional alias entries linking aws.lambda.function_name ↔ faas.name and aws.lambda.function_version ↔ faas.version, matching the existing pattern used by aws.lambda.aws_request_id ↔ faas.invocation_id. Also align PII classification on aws.lambda.aws_request_id from 'maybe' to 'false' to match its alias faas.invocation_id, so aliased attributes are treated consistently by scrubbing and product logic. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 11f8c5d. Configure here.
… aws.lambda attrs Four deprecated aws.lambda attributes had _status: null in their deprecation blocks, which skips Relay's backfill migration for spans still using the old keys. Set them all to 'backfill'. Also align aws.lambda.function_version PII to 'false' to match its faas.version alias, fixing a metadata mismatch that would cause inconsistent scrubbing depending on which key is present. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
| replacement: 'faas.invocation_id', | ||
| reason: 'This attribute is being deprecated in favor of faas.invocation_id', | ||
| }, | ||
| aliases: [FAAS_INVOCATION_ID], | ||
| changelog: [ | ||
| { version: 'next', description: 'Deprecated aws.lambda.aws_request_id in favor of faas.invocation_id' }, | ||
| { version: '0.7.0', prs: [369], description: 'Added aws.lambda.aws_request_id attribute' }, | ||
| ], | ||
| }, | ||
| [AWS_LAMBDA_EXECUTION_DURATION_IN_MILLIS]: { | ||
| brief: 'The execution duration of the Lambda function invocation in milliseconds', |
There was a problem hiding this comment.
Bug: The TypeScript DeprecationInfo interface is missing the status field, which is present in the Python equivalent and the source JSON models.
Severity: MEDIUM
Suggested Fix
Modify the generateMetadataTypes() function in generate_attributes.ts to include the status?: DeprecationStatus field in the DeprecationInfo interface definition. This will align the TypeScript type with the Python class and the underlying JSON data model.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.
Location: javascript/sentry-conventions/src/attributes.ts#L16732-L16751
Potential issue: The code generation script `generate_attributes.ts` fails to include
the `status` field when creating the TypeScript `DeprecationInfo` interface. The script
correctly reads the `_status` value from the JSON models and includes it in the Python
`DeprecationInfo` class, but omits it from the TypeScript definition. This prevents
TypeScript consumers from accessing the deprecation status (e.g., "backfill",
"normalize"), which is necessary for correctly handling attribute migration strategies.
This creates an inconsistency between the Python and TypeScript libraries.
There was a problem hiding this comment.
This is beyond the scope of this PR
#6498) When span streaming is enabled via the trace_lifecycle experiment, use sentry_sdk.traces.start_span instead of start_transaction so the function span is emitted as a span envelope item with OTel-compatible attributes (cloud.provider, cloud.platform, faas.*, aws.lambda.*). Also adds CLOUD_PLATFORM.AWS_LAMBDA constant and updates the test server helper to route span envelope items into a separate span_items list so tests can assert on streamed spans independently of error envelopes. Depends on getsentry/sentry-conventions#414 being shipped first as it introduces a number of the conventions used here Fixes PY-2307 Fixes #6005
Add OTel-aligned attributes for FaaS and AWS Lambda context:
Deprecate corresponding AWS Lambda-specific attributes in favor of the OTel-aligned equivalents.
Refs PY-2307