Fix span deduplication via correct ordering of adjusters

[cdanis]

Which problem is this PR solving?

• Resolves [Bug]: ElasticSearch storage not deduplicating multiply-archived spans #6001 (again). If ClockSkew adjuster is run before DedupeBySpanHash, it will add warnings to spans with duplicate span IDs, which affect the hash code, which means that you "dedupe" to two copies of each span, not one.

Description of the changes

• Change the order of Adjusters so that DedupeBySpanHash runs before ClockSkew

How was this change tested?

• In production, lightly
• Also unit tested

Checklist

• I have read https://github.com/jaegertracing/jaeger/blob/master/CONTRIBUTING_GUIDELINES.md
• I have signed all commits
• I have added unit tests for the new functionality
• I have run lint and test steps successfully
  • for jaeger: make lint test
  • for jaeger-ui: yarn lint and yarn test

[cdanis]

I am not sure how to add unittests for this and would welcome advice.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.41%. Comparing base (bf06acf) to head (b5703ea).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6116   +/-   ##
=======================================
  Coverage   96.41%   96.41%           
=======================================
  Files         353      353           
  Lines       20135    20135           
=======================================
  Hits        19414    19414           
  Misses        535      535           
  Partials      186      186           

Flag	Coverage Δ
badger_v1	8.32% <0.00%> (ø)
badger_v2	1.68% <0.00%> (ø)
cassandra-4.x-v1	14.39% <0.00%> (ø)
cassandra-4.x-v2	1.62% <0.00%> (ø)
cassandra-5.x-v1	14.39% <0.00%> (ø)
cassandra-5.x-v2	1.62% <0.00%> (ø)
elasticsearch-6.x-v1	18.51% <0.00%> (ø)
elasticsearch-7.x-v1	18.59% <0.00%> (+<0.01%)	⬆️
elasticsearch-8.x-v1	18.76% <0.00%> (ø)
elasticsearch-8.x-v2	1.67% <0.00%> (ø)
grpc_v1	9.52% <0.00%> (-0.01%)	⬇️
grpc_v2	7.01% <0.00%> (ø)
kafka-v1	8.88% <0.00%> (ø)
kafka-v2	1.68% <0.00%> (ø)
memory_v2	1.68% <0.00%> (ø)
opensearch-1.x-v1	18.64% <0.00%> (+<0.01%)	⬆️
opensearch-2.x-v1	18.64% <0.00%> (+<0.01%)	⬆️
opensearch-2.x-v2	1.67% <0.00%> (ø)
tailsampling-processor	0.47% <0.00%> (ø)
unittests	95.33% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[yurishkuro]

Resolves 6001 (again)

can you elaborate why "again"? Are we missing a unit test that should catch the issue of ordering?

[cdanis]

On Wed, Oct 23, 2024 at 6:47 PM Yuri Shkuro ***@***.***> wrote: can you elaborate why "again"? Are we missing a unit test that should catch the issue of ordering?

Yes, we are. I would appreciate advice on the best existing test to add that to.

…

[yurishkuro]

Can be a new test, we have several in the directory

[cdanis]

ok @yurishkuro ptal