Several instances of "first seen" and other fields assume an ordered input.

[tkaemming]

While doing some research on supporting fingerprint disassociation, I found many columns that assume that the event input stream is ordered by the event occurrence time. This assumption is incorrect for a lot of reasons, but mobile traffic is probably the most significant one.

This applies to at least the following columns (this list is not necessarily exhaustive):

• Group.first_seen
• Group.last_seen
• Group.first_release
• Group.score, since this is derived from Group.last_seen
• GroupRelease.first_seen
• ReleaseEnvironment.first_seen
• TagValue.first_seen (uses wall clock time, rather than event time)
• TagValue.last_seen (uses wall clock time, rather than event time)
• GroupTagValue.first_seen (uses wall clock time, rather than event time)
• GroupTagValue.last_seen (uses wall clock time, rather than event time)

[tkaemming]

I also just realized that this is going to be the case for reprocessed events, which can be delayed up to 10 days by default.

[tkaemming]

{,Group}TagValue.{first,last}_seen also use the current wall clock time for mutations, rather than the provided event timestamp.

[tkaemming]

This "last-write-wins by the receiving server wall clock time" behavior can also yield some confusing behavior for group fields like culprit, message, level, etc. (basically any of these fields) when comparing the group details with the reverse chronologically sorted "related events" list.

[BYK]

Closing this issue due to staleness. Feel free to comment here if you think we should still work on this.

[untitaker]

This is still an issue.

[untitaker]

Another fun fact is that first_seen on GroupEnvironment is updated with the current time instead of the event's timestamp in the same way that Group.first_seen is.