chore: no lifecycle context to shutdown ProviderQueryManager

[gammazero]

Call Close instead of cancelling long-lived context.

[codecov]

Codecov Report

Attention: Patch coverage is 73.91304% with 6 lines in your changes missing coverage. Please review.

Project coverage is 60.43%. Comparing base (f6befaf) to head (e976801).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
...uting/providerquerymanager/providerquerymanager.go	68.42%	6 Missing ⚠️

@@           Coverage Diff           @@
##             main     #734   +/-   ##
=======================================
  Coverage   60.42%   60.43%           
=======================================
  Files         245      245           
  Lines       31063    31069    +6     
=======================================
+ Hits        18771    18775    +4     
  Misses      10623    10623           
- Partials     1669     1671    +2     

Files with missing lines	Coverage Δ
bitswap/client/client.go	89.92% <100.00%> (+0.07%)	⬆️
...uting/providerquerymanager/providerquerymanager.go	87.70% <68.42%> (-0.17%)	⬇️

... and 11 files with indirect coverage changes

[hsanjuan]

I understand the part about auto-starting it... but removing the context? It is nice that things die on context cancellation by themselves.

[gammazero]

@hsanjuan IMO Contexts are best for request-scoped operations. For globally shared resources, traditional patterns may be better. Passing a context info New means the caller needs to understand whether the context is used to cancel the call to New, or whether it is used in place of a Close function for the object being created.

Also, passing the context into New generally requires storing the context in the struct that defines the object. According to the documentation, contexts should never be stored in struct type, but rather it should be passed through as an argument to a function. There are a few exceptions; context.CancelFunc is one such exception that can be put in a structure.

[hsanjuan]

@hsanjuan IMO Contexts are best for request-scoped operations. For globally shared resources, traditional patterns may be better. Passing a context info New means the caller needs to understand whether the context is used to cancel the call to New, or whether it is used in place of a Close function for the object being created.

Also, passing the context into New generally requires storing the context in the struct that defines the object. According to the documentation, contexts should never be stored in struct type, but rather it should be passed through as an argument to a function. There are a few exceptions; context.CancelFunc is one such exception that can be put in a structure.

Interesting! I've somehow always considered that contexts could be used for objects' lifecycle management because deriving a context and cancelling the mother of all contexts facilitated cascading cleanup of things, rather than remembering to Close() here and there. Thanks for the pointer! I will not discuss The Go Way :)

[gammazero]

I've somehow always considered that contexts could be used for objects' lifecycle management

That is still a valid use for context, I just have a particular opinion. I think we need a consistent design paradigm that we can all mostly agree on. So, I pose it as a question to the maintainers here: Do we generally want to limit the scope of a context to that of a request or session, or do we also want to use contexts to for objects' lifecycle management?

[hsanjuan]

(We can merge and discuss this later, I think this is an improvement and shouldn't stay behind waiting on discussions)