feat(attributes): expand grpc attributes

[lucas-zimerman]

Description

Adds attribute conventions for the Google gRPC rich error model (google.rpc.error_details.proto), under the rpc.grpc.error.* namespace:

• rpc.grpc.error.error_info.{reason,domain,metadata.<key>}
• rpc.grpc.error.bad_request.field_violations
• rpc.grpc.error.retry_info.retry_delay_in_ms
• rpc.grpc.error.debug_info.{detail,stack_entries}
• rpc.grpc.error.precondition_failure.violations
• rpc.grpc.error.resource_info.{resource_type,resource_name,description,owner}
• rpc.grpc.error.quota_failure.violations

Field names and shapes were verified against google/rpc/error_details.proto (AIP-193 error model) for fidelity. Structured/repeated fields (e.g. field_violations, violations) are encoded as JSON-stringified array entries, following the existing mcp.request.argument. precedent. Attributes that may carry user- or resource-identifying data (e.g. error_info.metadata.<key>, debug_info.detail, debug_info.stack_entries, resource_info.resource_name, resource_info.owner, quota_failure.violations) are documented as PII and gated behind sendDefaultPii.

Unblocks getsentry/sentry-dart#3791.

PR Checklist

• I have run yarn test and verified that the tests pass.
• I have run yarn generate to generate and format code and docs.

If an attribute was added:

• The attribute is in a namespace (e.g. nextjs.function_id, not function_id)
• I have used the correct value for apply_scrubbing (i.e. manual or auto. Use never only for values that should never be scrubbed such as IDs)

[github-actions]

Semver Impact of This PR

🟡 Minor (new features)

📋 Changelog Preview

This is how your changes will appear in the changelog.
Entries from this PR are highlighted with a left border (blockquote style).

---

New Features ✨

• (ai) Add granular cost attributes for cache and reasoning by vgrozdanic in #461

• (attributes) Expand grpc attributes by lucas-zimerman in #460

---

_{🤖 This preview updates automatically when you update the PR.}

[lucas-zimerman]

I used claude to fix the attributes.py, not sure why when I generate it manually it formats the entire file

[buenaflor]

I'm not sure if we should nest under rpc, gRPC themselves use a top level grpc.* (at least for metrics)

https://grpc.io/docs/guides/opentelemetry-metrics/

[Lms24]

Theoretically, we have the error namespace (also in OTel) which "defines the shared attributes used to report an error". But I get that the attributes here are very specific to GRPC, with some exceptions.

Also to confirm: We don't capture an exception in the SDK because we explicitly only want to record the error on the span? I assume because the error is not from the application but happened wherever the procedure was executed?

I'm curious on other reviewers opinions here. Should we stay GRPC-specific or would we prefer adding a bunch of specific attributes to the error namespace?

[lucas-zimerman]

I'm not sure if we should nest under rpc, gRPC themselves use a top level grpc.* (at least for metrics)

https://grpc.io/docs/guides/opentelemetry-metrics/

renamed to grpc.* on f0c8eed

Except for rpc.grpc.status_code that already existed on sentry-conventions.

[lucas-zimerman]

Theoretically, we have the error namespace (also in OTel) which "defines the shared attributes used to report an error". But I get that the attributes here are very specific to GRPC, with some exceptions.

Also to confirm: We don't capture an exception in the SDK because we explicitly only want to record the error on the span? I assume because the error is not from the application but happened wherever the procedure was executed?

I'm curious on other reviewers opinions here. Should we stay GRPC-specific or would we prefer adding a bunch of specific attributes to the error namespace?

OTel's error.* namespace is intentionally minimal: it's really just error.type (a low-cardinality classifier like an exception class name or domain code), plus a deprecated error.message. It's explicitly not meant to carry rich, structured payloads. The docs even call out that message-like fields cause "unbounded cardinality" problems on spans.

Also. Capturing an exception client-side felt low-value here. The client only has the serialized google.rpc error detail, while the real exception with full context typically already exists server-side (when that service is also Sentry-instrumented). Turning every non-OK status into a client-side exception would also add noise for cases that are expected/handled control flow rather than bugs. Worth documenting that reasoning, but happy to make it opt-in if reviewers want richer client-side capture for unattended/uninstrumented peers.