mirror of
https://github.com/hibiken/asynq.git
synced 2026-04-26 07:25:56 +03:00
[GH-ISSUE #381] [FEATURE REQUEST] Add ability to provide a base context for handler invocations #1180
Labels
No labels
CLI
bug
designing
documentation
duplicate
enhancement
good first issue
good first issue
help wanted
idea
invalid
investigate
needs-more-info
performance
pr-welcome
pull-request
question
wontfix
work in progress
work in progress
work-around-available
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/asynq#1180
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @binaek on GitHub (Jan 15, 2022).
Original GitHub issue: https://github.com/hibiken/asynq/issues/381
Originally assigned to: @hibiken on GitHub.
Is your feature request related to a problem? Please describe.
I am unable to set a base
contextfor thehandlerFuncinvocations.Describe the solution you'd like
Something along the lines of what
http.Serverprovides:A nice adaptation would be
BaseContext func(context.Context) context.Context.This will allow invocation contexts to be derived from a known
context.Context@hibiken commented on GitHub (Jan 16, 2022):
@binaek Thank you for creating this feature request!
I think it makes sense to add this
BaseContexttoConfig.But before we make the change, could you describe possible use cases? So that we have more concrete motivation to make this change :)
@binaek commented on GitHub (Jan 16, 2022):
@hibiken
The use case that I am struggling with is as such:
The application uses Context as a DI container for application wide services like DB connection, Root loggers, telemetry etc.
The context also uses a signal.NotifyContext and so deadlines and cancellations never reach the handlers till an explicit call to Stop or Shutdown
@hibiken commented on GitHub (Jan 17, 2022):
I see. I'm onboard with adding this field to
Config.Just to clarify, the proposed function's signature is:
The input to the
BaseContextis the context that would normally be passed to Handler (in the absence of thisBaseContextfunction provided by the user), is that correct? So in effect thisBaseContextfunction works like a middleware where user gets an opportunity to decorate the context before its passed to the Handler invocation? Let me know if I misunderstood your proposal.@hibiken commented on GitHub (Feb 16, 2022):
Closed via #386