Skip to content

ref(spans): Remove unused end_timestamp from Span NamedTuple#109788

Merged
untitaker merged 9 commits intomasterfrom
ref/remove-span-end-timestamp
Mar 16, 2026
Merged

ref(spans): Remove unused end_timestamp from Span NamedTuple#109788
untitaker merged 9 commits intomasterfrom
ref/remove-span-end-timestamp

Conversation

@untitaker
Copy link
Member

@untitaker untitaker commented Mar 3, 2026

This is a leftover from the time we used end_timestamp to trim segments intelligently. Now we moved to unsorted sets, and it's no longer needd.

Co-Authored-By: Claude noreply@anthropic.com

The end_timestamp field on the buffer's Span NamedTuple was dead code.
_prepare_payloads stored timestamps as dict values, but the only caller
used p.sadd(set_key, *set_members.keys()), discarding the values
entirely. Simplify _prepare_payloads to return a set instead of a dict.

Co-Authored-By: Claude <noreply@anthropic.com>
@github-actions github-actions bot added the Scope: Backend Automatically applied to PRs that change backend components label Mar 3, 2026
@untitaker untitaker marked this pull request as ready for review March 3, 2026 17:01
@untitaker untitaker requested review from a team as code owners March 3, 2026 17:01
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we remove this assertion as well? also, I'm not sure if start_timestamp is used.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change

The start_timestamp and end_timestamp assertions in validate_span_event
only protected downstream systems, not the span buffer itself. Downstream
consumers should validate their own inputs.

Co-Authored-By: Claude <noreply@anthropic.com>
Copy link
Member

@lvthanh03 lvthanh03 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The schema still requires start_timestamp and end_timestamp, the spans we produce to buffered-segments still have these attributes right?

https://github.com/getsentry/sentry-kafka-schemas/blob/main/schemas/ingest-spans.v1.schema.json#L91-L92

https://github.com/getsentry/sentry-kafka-schemas/blob/main/schemas/ingest-spans.v1.schema.json#L35-L42

@untitaker
Copy link
Member Author

@lvthanh03 yeah but i would argue the span buffer should not validate this constraint. segments consumer should protect itself

Address review feedback: fix set[str | bytes, float] -> set[str | bytes]
and update docstring to reflect the method now returns a set, not a dict.
…-timestamp

# Conflicts:
#	src/sentry/spans/buffer.py
#	tests/sentry/spans/consumers/process/test_consumer.py
Copy link
Contributor

@cursor cursor bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

Fix All in Cursor

Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.

New tests added on master also used end_timestamp in Span() constructors.
@github-actions
Copy link
Contributor

Backend Test Failures

Failures on 7c13d1f in this run:

tests/sentry/spans/consumers/process/test_consumer.py::test_schema_validator_rejects_string_timestampslog
tests/sentry/spans/consumers/process/test_consumer.py:205: in test_schema_validator_rejects_string_timestamps
    with pytest.raises(InvalidMessage):
E   Failed: DID NOT RAISE <class 'arroyo.dlq.InvalidMessage'>

This test validated end_timestamp type checking which we've removed.
@untitaker untitaker merged commit e40ec24 into master Mar 16, 2026
62 checks passed
@untitaker untitaker deleted the ref/remove-span-end-timestamp branch March 16, 2026 18:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Scope: Backend Automatically applied to PRs that change backend components

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants