Use find providers async context

[hannahhoward]

Goals

In Bitswap, when I call FindProvidersAsync on a call to the ProviderQueryManager, the ultimate call to DHT should retain the context I used with the ProviderQueryManager.

Background

Since I imagine the review here may or may not have ever even worked with the ProviderQueryManager in Bitswap, here's some background on it.

Essentially I wrote this piece of code almost three years ago, which has two purposes:

• Limit the number of concurrent DHT queries running at the same time
• Reuse queries for the same CID across sessions (and or the global context if for some reason you're not using sessions)

It is a lot of code to manage all that, and looking at it now, I'm like, "wow new Go programmer me you were really go-routine happy back then". It all works (cause you know, this runs in every bitswap) but could be simplified a lot.

But, today is not that day.

Implementation

I was suprised to find the context I passed to initialize a bitswap session in Lassie was not being retained here. Instead, I was getting global context. Digging into this, I found what I can only assume is a bug in the code I wrote. While the session context is passed across the go-routine barrier, it isn't even used. Instead the global context is. Perhaps because of the wonderfully similar named variables npqm and pqm to represent the structs that have the local and global context respectively.

I am pretty sure this is a bug, cause otherwise why pass the session context over the go-routine variable? So I corrected it.

For Discussion

Looking at my code... well I'm not actually sure of intent here. There are implications to using the session context -- if two queries are called for the same CID in two different sessions, the first sessions context is used, so if that session gets cancelled, then the others query is also cancelled. Maybe that's why I used the global context? But then why pass the context across the go-routine at all (alternate solution: don't do so for clarity).

The use case we're dealing with is trying to extract value's from the context. Maybe that's too much of an edge case to optimize for.

But this PR is aimed to identify the bug (there's a context passed over a go routine but not used) and let you all decide the right outcome.

[codecov]

Codecov Report

Merging #172 (e9a7c12) into main (fe55533) will decrease coverage by 39.58%.
Report is 2 commits behind head on main.
The diff coverage is 0.00%.

❗ Current head e9a7c12 differs from pull request most recent head add7775. Consider uploading reports for the commit add7775 to get more accurate results

@@             Coverage Diff             @@
##             main     #172       +/-   ##
===========================================
- Coverage   65.58%   26.01%   -39.58%     
===========================================
  Files         207      100      -107     
  Lines       25540    11061    -14479     
===========================================
- Hits        16750     2877    -13873     
- Misses       7323     7842      +519     
+ Partials     1467      342     -1125     

Files	Coverage Δ
...ernal/providerquerymanager/providerquerymanager.go	0.00% <0.00%> (-85.48%)	⬇️

... and 193 files with indirect coverage changes

[aschmahmann]

Assuming this is low priority for now, if not reach out.

[Jorropo]

@hannahhoward I would like to merge your pull request because it fixes an issue with bitswap where opentelemetry traces between bitswap inputs are not linked with the content router however your fix bring an other issue, the providerquerymanager deduplicate FindProvidersAsync call.

In other words if this sequence happen:

• Session A starts to download Qmfoo.
• Session B starts to download Qmfoo
• Session A starts a FindProvidersAsync for Qmfoo.
• Session B starts a FindProvidersAsync for Qmfoo.
• Sessions's A context is canceled.
• Session's B FindProvidersAsync call fails because it has been dedupped to sessions's A call. The previous code is correct.

This is captured by the TestCancelOneRequestDoesNotTerminateAnother failing test.
The previous version of the code you changed is correct, by using a context scoped to a broader context, this is a nuclear way to ensure this wont happen (something smart could do refcounting, but this only solves cancellations, not Values and thus don't help me with my tracing.)

I'm not sure why bitswap needs to deduplicate content routing queries like that. I would suggest we remove all of this if possible, how likely is it you have two sessions requesting the same blocks anyway ?
And if this is an issue I think this should be extracted in a cachingContentRouter in it's own package, so users can DI all the flow.

---

Is there something else I am missing, do you think of anything bad that will happen when I remove the providerquerymanager ?