Description
Currently, SentrySpanArguments includes an endTimestamp property that is passed to the SentrySpan constructor. If an endTimestamp is set, the span ends itself immediately, debug-logs itself to the console and emits the spanEnd client hook event. The funny thing is that by our public API, this is dead code. StartSpanOptions don't define endTimestamp at all.
Unfortunately though, when we convert StartSpanOptions to SentrySpanArguments in parseSentrySpanArguments, we spread the options into the new arguments object. Meaning users can simply ignore TS and still get the span to end immediately by adding the endTimestamp property.
Removing endTimestamp is technically a breaking change because SentrySpanArguments are exported from @sentry/core. Just removing the dead code in the SentrySpan constructor alone also feels wrong. So I suggest we do this as a cleanup task in one go in v11.
to external contributors: please do not pick up this issue!
Description
Currently,
SentrySpanArgumentsincludes anendTimestampproperty that is passed to theSentrySpanconstructor. If an endTimestamp is set, the span ends itself immediately, debug-logs itself to the console and emits thespanEndclient hook event. The funny thing is that by our public API, this is dead code.StartSpanOptionsdon't defineendTimestampat all.Unfortunately though, when we convert
StartSpanOptionstoSentrySpanArgumentsinparseSentrySpanArguments, we spread the options into the new arguments object. Meaning users can simply ignore TS and still get the span to end immediately by adding theendTimestampproperty.Removing
endTimestampis technically a breaking change becauseSentrySpanArgumentsare exported from@sentry/core. Just removing the dead code in theSentrySpanconstructor alone also feels wrong. So I suggest we do this as a cleanup task in one go in v11.to external contributors: please do not pick up this issue!