Upgrade storage integration test: Use V2 Archive ReaderWriter

[ekefan]

Which problem is this PR solving?

• Part of Upgrade storage integration tests to Storage v2 API #6366

Description of the changes

For es v1 storage integration test:

• replaced ArchiveSpanReader with ArchiveTraceReader
• replaced ArchiveSpanWriter with ArchiveTraceWriter

How was this change tested?

• CI tests

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: npm run lint and npm run test

[yurishkuro]

looks like some archive tests are failing

    --- ❌ FAIL: TestElasticsearchStorage/ArchiveTrace (0.00s)
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
	panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x22fe57b]

goroutine 65 [running]:
testing.tRunner.func1.2({0x2532840, 0x3a10eb0})
	/opt/hostedtoolcache/go/1.23.4/x64/src/testing/testing.go:1632 +0x3fc
testing.tRunner.func1()
	/opt/hostedtoolcache/go/1.23.4/x64/src/testing/testing.go:1635 +0x6b6
panic({0x2532840?, 0x3a10eb0?})
	/opt/hostedtoolcache/go/1.23.4/x64/src/runtime/panic.go:785 +0x132
github.com/jaegertracing/jaeger/plugin/storage/integration.(*StorageIntegration).testArchiveTrace.func1(0x6c0f40?)
	/home/runner/work/jaeger/jaeger/plugin/storage/integration/integration.go:214 +0x47b
github.com/jaegertracing/jaeger/plugin/storage/integration.(*StorageIntegration).waitForCondition(0x2a7de18?, 0xc000523040, 0xc000439e58)
	/home/runner/work/jaeger/jaeger/plugin/storage/integration/integration.go:128 +0x165

[ekefan]

there's no new change with the recent push... just trying to update the branch.

I will get back to these issues later in my day.

[ekefan]

Hello @yurishkuro,

I can't find the cause of this bug, but for elastic search and open search, the testArchiveTrace test fails; the archive trace reader returns an empty trace...
I want to try updating the reader before the writer, but I'd be glad to get any help or way forward from you.
Thanks alot.

[yurishkuro]

Did you look at the logs? I see nil pointer segfaults, that should be easy to troubleshoot.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.94%. Comparing base (4ac036b) to head (68655a8).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6489      +/-   ##
==========================================
+ Coverage   95.93%   95.94%   +0.01%     
==========================================
  Files         365      365              
  Lines       20616    20616              
==========================================
+ Hits        19778    19781       +3     
+ Misses        638      636       -2     
+ Partials      200      199       -1     

Flag	Coverage Δ
badger_v1	9.92% <ø> (ø)
badger_v2	1.84% <ø> (ø)
cassandra-4.x-v1-manual	14.93% <ø> (ø)
cassandra-4.x-v2-auto	1.83% <ø> (ø)
cassandra-4.x-v2-manual	1.83% <ø> (ø)
cassandra-5.x-v1-manual	14.93% <ø> (ø)
cassandra-5.x-v2-auto	1.83% <ø> (ø)
cassandra-5.x-v2-manual	1.83% <ø> (ø)
elasticsearch-6.x-v1	19.30% <ø> (ø)
elasticsearch-7.x-v1	19.38% <ø> (ø)
elasticsearch-8.x-v1	19.56% <ø> (ø)
elasticsearch-8.x-v2	1.84% <ø> (ø)
grpc_v1	10.90% <ø> (ø)
grpc_v2	7.89% <ø> (ø)
kafka-3.x-v1	10.21% <ø> (ø)
kafka-3.x-v2	1.84% <ø> (ø)
memory_v2	1.84% <ø> (ø)
opensearch-1.x-v1	19.44% <ø> (ø)
opensearch-2.x-v1	19.44% <ø> (ø)
opensearch-2.x-v2	1.84% <ø> (ø)
tailsampling-processor	0.48% <ø> (ø)
unittests	94.83% <ø> (+0.01%)	⬆️

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.

[ekefan]

@yurishkuro, @mahadzaryab1, I have two questions please:

• When all jaeger storage backends are upgraded to v2, will the Archive ReaderWriter fields still exist in StorageIntegration for the storage integration tests?
• Will testArchiveTrace still be part of the integration tests?

[mahadzaryab1]

I'm currently in the process of trying to completely phase out the difference between primary and archive interfaces in #6567. If that can be pulled off, then this PR can initialize primary and archive storage in the same way.

[ekefan]

@yurishkuro, @mahadzaryab1, I have two questions please:

• When all jaeger storage backends are upgraded to v2, will the Archive ReaderWriter fields still exist in StorageIntegration for the storage integration tests?
• Will testArchiveTrace still be part of the integration tests?

My question has been answered in the description of #6567

[mahadzaryab1]

@ekefan My apologies that this PR has been held back. I think it might be good to hold off on this PR until #6625 is merged. That should greatly simplify this PR and will likely only require the archive reader/writer to be upgraded in one place.

[ekefan]

@ekefan My apologies that this PR has been held back. I think it might be good to hold off on this PR until #6625 is merged. That should greatly simplify this PR and will likely only require the archive reader/writer to be upgraded in one place.

@mahadzaryab1 The problem was never with the way es or os was reading (as I was suspecting)... And since #6567 was merged, I discovered that it wasn't the distinction between archive or primary data either, I was not waiting for the storage backend to update documents before accessing the traces 😂😂. But its done now😃.

#6625 makes total sense, we can just implement Archive Trace Reader-Writer as I have done here, then close this PR

[yurishkuro]

please rebase - most of these changes are no longer needed since #6625, only ES test needs to be upgraded