Skip to content

ref: Undeprecate sentry.observed_timestamp_nanos - #174

Merged
loewenheim merged 1 commit into
mainfrom
sebastian/sentry-observed-timestamp-nanos
Oct 29, 2025
Merged

ref: Undeprecate sentry.observed_timestamp_nanos#174
loewenheim merged 1 commit into
mainfrom
sebastian/sentry-observed-timestamp-nanos

Conversation

@loewenheim

Copy link
Copy Markdown
Contributor

Description

#137 added sentry.observed_timestamp_nanos as a deprecated attribute and sentry._internal.observed_timestamp_nanos as its non-deprecated replacement. However, adding the attribute as deprecated was probably a mistake because it is in active use and no concrete plan was made for a migration to the _internal version. It's also questionable whether this attribute should be hidden from users in the first place.

Since the _internal version is not used anywhere and not written by Relay, I propose that we delete it and mark the non-_internal version as not deprecated.

PR Checklist

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

@cleptric

Copy link
Copy Markdown
Member

How can we make sure this is not displayed to the user? Can't we update the places it's used?

@Dav1dde

Dav1dde commented Oct 20, 2025

Copy link
Copy Markdown
Member

How can we make sure this is not displayed to the user? Can't we update the places it's used?

This is already actively displayed and already actively added to (OTeL) Spans, Logs and Trace Metrics. The UI even uses it show some sort of ingestion delay iirc.

Also if this is not desired (which it very well may be), it does not represent the status quo. I think it is better to have conventions which represent the current state rather than a desired state nobody is working towards.

If the attribute should be 'internal' then also somebody should be actively working on the migration of the product(s).

I asked Sebastian to represent the status quo, as I assumed there is no one actively working on that migration, is this not the case?

@cleptric

Copy link
Copy Markdown
Member

The conventions very well were launched for a desired end stated, we just got into a habit of adding more and more stuff.
That we display sentry.observed_timestamp_nanos in the product is more a bug than a feature, how should any user know what this even means?

Anyways, if it unblocks stuff, we can merge this, but we apparently need a high level convo about this.

@Dav1dde

Dav1dde commented Oct 20, 2025

Copy link
Copy Markdown
Member

That we display sentry.observed_timestamp_nanos in the product is more a bug than a feature, how should any user know what this even means?

I think it's just on a hover and renamed to something reasonable.
image

This just highlights a fundamental issue, maybe we shouldn't tie to the visibility (frontend state) to the attribute name, but instead track that separately as metadata for an attribute. If for changing the visibility state we have to change ingestion and backfilll for 90 days, that seems pretty bad.

This also came up recently, where we may want to track frontend aliasing also in the conventions.

#137 added
`sentry.observed_timestamp_nanos` as a deprecated attribute and
`sentry._internal.observed_timestamp_nanos` as its non-deprecated
replacement. However, adding the attribute as deprecated was probably a
mistake because it is in active use and no concrete plan was made for a
migration to the `_internal` version. It's also questionable whether
this attribute should be hidden from users in the first place.

Since the `_internal` version is not used anywhere and not written by
Relay, I propose that we delete it and mark the non-`_internal` version
as not deprecated.
@loewenheim
loewenheim force-pushed the sebastian/sentry-observed-timestamp-nanos branch from e1561e7 to 0669ce9 Compare October 29, 2025 09:51
@loewenheim
loewenheim merged commit 4c7cda0 into main Oct 29, 2025
9 checks passed
@loewenheim
loewenheim deleted the sebastian/sentry-observed-timestamp-nanos branch October 29, 2025 13:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants