mirror of
https://github.com/hibiken/asynq.git
synced 2026-04-26 15:35:55 +03:00
[GH-ISSUE #622] [FEATURE REQUEST] fetch metadata of task from within the message #1318
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#1318
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 @nikhilsaraf on GitHub (Feb 27, 2023).
Original GitHub issue: https://github.com/hibiken/asynq/issues/622
Originally assigned to: @hibiken on GitHub.
Is your feature request related to a problem? Please describe.
From within my messageHandler, I am trying to enqueue a chained message with the same parameters as the originating message (retention policy, max retry).
Today, this is not easy to do because I cannot access the
taskInfofrom within the message directly.I can fetch the
taskInfoby passing in(queueName, taskID)to the inspector since I have the taskID from the asynq.Task but not thequeueName.Describe the solution you'd like
asynq.Taskto include thequeueName. Then I can directly get the metadata using the inspector.asynq.Taskthen that would be even better and I can access that directly without having to fetch it from the inspector.Describe alternatives you've considered
To solve this today, I'm currently getting a list of all the queues in the system and cycling through them to find the associated task for the given taskID. Using taskInfo I can get the required metadata (retention policy, max retry).
However, this can be problematic because:
- if two queues have different messages with the same taskID then it could end up selecting the incorrect message
- this approach is just an inefficient way to fetch the metadata for a given message
Additional context
This is the function I wrote to fetch the metadata:
@rclark commented on GitHub (Feb 26, 2025):
I would go a step further than just exposing the queue name, and just ask that the
TaskInfodata ought to be made available via some method of theTaskthat each iteration of the handler receives. Just like we can ask fortask.Payload()to find the job's inputs, we should be able to ask for something liketask.Info()to learn about its state, number of failures, and so on.