[v2] Implement GetDependencies for memory backend

[Manik2708]

Which problem is this PR solving?

• Fixes a part of: [Feature]: Upgrade Memory Storage to v2 API #7052

Description of the changes

• Implement GetDependencies for memory backend

How was this change tested?

• Unit 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

[Manik2708]

I have a question: Do we need to consider the case when start time is 0 but end time is not? Currently it will throw an error in this case!

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.19%. Comparing base (0d02bc8) to head (860ba44).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7154      +/-   ##
==========================================
- Coverage   96.21%   96.19%   -0.03%     
==========================================
  Files         361      361              
  Lines       21779    21838      +59     
==========================================
+ Hits        20955    21006      +51     
- Misses        616      622       +6     
- Partials      208      210       +2     

Flag	Coverage Δ
badger_v1	9.87% <ø> (ø)
badger_v2	1.90% <ø> (ø)
cassandra-4.x-v1-manual	14.85% <ø> (ø)
cassandra-4.x-v2-auto	1.89% <ø> (ø)
cassandra-4.x-v2-manual	1.89% <ø> (ø)
cassandra-5.x-v1-manual	14.85% <ø> (ø)
cassandra-5.x-v2-auto	1.89% <ø> (ø)
cassandra-5.x-v2-manual	1.89% <ø> (ø)
elasticsearch-6.x-v1	20.69% <ø> (ø)
elasticsearch-7.x-v1	20.77% <ø> (ø)
elasticsearch-8.x-v1	20.95% <ø> (ø)
elasticsearch-8.x-v2	1.90% <ø> (ø)
grpc_v1	11.41% <ø> (ø)
grpc_v2	1.90% <ø> (ø)
kafka-3.x-v1	10.14% <ø> (ø)
kafka-3.x-v2	1.90% <ø> (ø)
memory_v2	1.90% <ø> (ø)
opensearch-1.x-v1	20.82% <ø> (ø)
opensearch-2.x-v1	20.82% <ø> (ø)
opensearch-2.x-v2	1.90% <ø> (ø)
query	1.90% <ø> (ø)
tailsampling-processor	0.51% <ø> (ø)
unittests	95.00% <100.00%> (-0.03%)	⬇️

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.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[yurishkuro]

Why does this need to be in this function instead of in the tenant? The tenant has additional checks for time anyway, I don't see the value in splitting the logic

[Manik2708]

The reason is: Tenant is just storing the traces. The logic in tenant expects that the start and end time of trace is already found because tenant doesn't iterates the spans it just sees if a trace with same trace id already exists and if yes then it appends the resource spans to that trace and if not then it creates a new trace. This same is hapenning here. Firstly we iterate the spans of a trace and find the start and end time and then send them to tenant. Now tenant sees if there exists a trace already, if yes then append the spans to that trace and update the start and end time (if bounds are out of the range of start and end time) and if not then just create new trace with start and time. How are we expected to find start and end time of trace in tenant?

[yurishkuro]

tenant can run the same loop you're running here to identify the timestamps. The memory storage itself has no use for those timestamps, so why does it need to know about them and increase the API surface of the tenant?

[Manik2708]

Does the new way looks fine?