You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The trace search limit is applied before the sort order modifier when looking up traces, at least for the all-in-one container build. This results in a random and unpredictable set of traces
If you have (say) 1000 traces and want the 10 most recent, you'd expect searching with "most recent first" and a limit of 10 to find them. But in fact, you will get some arbitrary set of those 1000 traces, and that arbitrary selection will then be sorted in order of most to least recent.
In SQL DB terms, this is incorrectly applying the LIMIT before the ORDER BY.
Unclear if this affects other backends yet. Looking to see if there are canned Cassandra or ElasticSearch backends I can play with to validate.
The text was updated successfully, but these errors were encountered:
I see - the memstore implementation likely doesn't provide stable search, because it uses hash maps internally. It's doable, but doesn't seem too important.
The trace search limit is applied before the sort order modifier when looking up traces, at least for the all-in-one container build. This results in a random and unpredictable set of traces
If you have (say) 1000 traces and want the 10 most recent, you'd expect searching with "most recent first" and a limit of 10 to find them. But in fact, you will get some arbitrary set of those 1000 traces, and that arbitrary selection will then be sorted in order of most to least recent.
In SQL DB terms, this is incorrectly applying the LIMIT before the ORDER BY.
Unclear if this affects other backends yet. Looking to see if there are canned Cassandra or ElasticSearch backends I can play with to validate.
The text was updated successfully, but these errors were encountered: