Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: no lifecycle context to shutdown ProviderQueryManager #734

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

gammazero
Copy link
Contributor

@gammazero gammazero commented Dec 1, 2024

Call Close instead of cancelling long-lived context.

@gammazero gammazero requested a review from a team as a code owner December 1, 2024 05:46
Copy link

codecov bot commented Dec 1, 2024

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).

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

Impacted file tree graph

@@           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
Copy link
Contributor

hsanjuan commented Dec 3, 2024

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

@gammazero
Copy link
Contributor Author

@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
Copy link
Contributor

hsanjuan commented Dec 3, 2024

@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
Copy link
Contributor Author

gammazero commented Dec 4, 2024

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?

Use Close function instead.

Also, do not require calling Startup separately from new.
@hsanjuan
Copy link
Contributor

hsanjuan commented Dec 5, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants