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

• Incrementally swaps the fields of StorageIntegration to align with v2 storage api

  • replaced ArchiveSpanReader with ArchiveTraceReader
  • replaced ArchiveSpanWriter with ArchiveTraceWriter

• Updates test functions accordingly to work with the updated fields

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 96.00%. Comparing base (20bdd8d) to head (5d23f27).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6489   +/-   ##
=======================================
  Coverage   96.00%   96.00%           
=======================================
  Files         365      365           
  Lines       20616    20616           
=======================================
  Hits        19792    19792           
  Misses        626      626           
  Partials      198      198           

Flag	Coverage Δ
badger_v1	9.92% <ø> (ø)
badger_v2	1.84% <ø> (ø)
cassandra-4.x-v1-manual	15.08% <ø> (ø)
cassandra-4.x-v2-auto	1.83% <ø> (ø)
cassandra-4.x-v2-manual	1.83% <ø> (ø)
cassandra-5.x-v1-manual	15.08% <ø> (ø)
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.95% <ø> (ø)
grpc_v1	11.04% <ø> (ø)
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.81% <ø> (ø)

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]

@mahadzaryab1 PTAL

[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