Summary
Attributes.prepare() in src/main/java/dev/openfga/sdk/telemetry/Attributes.java:130 uses AttributeKey.stringKey() for every attribute. Per the OpenFGA telemetry spec and OTel conventions, some attributes should be numeric:
http.response.status_code should be int → AttributeKey.longKey()http.request.resend_count should be int → AttributeKey.longKey()
Impact
Downstream OTel pipelines (dashboards, alerts) that expect numeric types for these attributes will either fail or treat them incorrectly. For example, queries like status_code >= 400 won't work on string-typed values.
Proposed Fix
In Attributes.prepare(), use AttributeKey.longKey() for known numeric attributes, parsing the string value to long. The internal Map<Attribute, String> representation can stay as strings — only the OTel export needs correct types.
Prior Art
The Python SDK already fixed this same issue in PR #177.
Related
Summary
Attributes.prepare()insrc/main/java/dev/openfga/sdk/telemetry/Attributes.java:130usesAttributeKey.stringKey()for every attribute. Per the OpenFGA telemetry spec and OTel conventions, some attributes should be numeric:http.response.status_codeshould beint→AttributeKey.longKey()http.request.resend_countshould beint→AttributeKey.longKey()Impact
Downstream OTel pipelines (dashboards, alerts) that expect numeric types for these attributes will either fail or treat them incorrectly. For example, queries like
status_code >= 400won't work on string-typed values.Proposed Fix
In
Attributes.prepare(), useAttributeKey.longKey()for known numeric attributes, parsing the string value tolong. The internalMap<Attribute, String>representation can stay as strings — only the OTel export needs correct types.Prior Art
The Python SDK already fixed this same issue in PR #177.
Related