[GH-ISSUE #192] [FEATURE REQUEST] access to the real-executed queue name somewhere

kerem commented

2026-03-15 19:05:17 +03:00

Owner

Originally created by @ChristianYeah on GitHub (Sep 15, 2020).
Original GitHub issue: https://github.com/hibiken/asynq/issues/192

Originally assigned to: @hibiken on GitHub.

It seems like there is no way to get the queue name which is processing in especially when the StrictPriority is set to true

Originally created by @ChristianYeah on GitHub (Sep 15, 2020). Original GitHub issue: https://github.com/hibiken/asynq/issues/192 Originally assigned to: @hibiken on GitHub. It seems like there is no way to get the queue name which is processing in especially when the StrictPriority is set to true

kerem

2026-03-15 19:05:17 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-03-15 19:05:33 +03:00

Author

Owner

@hibiken commented on GitHub (Sep 15, 2020):

@ChristianYeah Thank you for opening this issue!

Which version of the package are you using? And do you have CLI (github.com/hibiken/asynq/tools/asynq) installed as well?

@hibiken commented on GitHub (Sep 15, 2020): @ChristianYeah Thank you for opening this issue! Which version of the package are you using? And do you have CLI (github.com/hibiken/asynq/tools/asynq) installed as well?

kerem commented

2026-03-15 19:05:38 +03:00

Author

Owner

@ChristianYeah commented on GitHub (Sep 15, 2020):

github.com/hibiken/asynq/tools/asynq

I'm using asynq v0.11.0 currently, and I installed the latest asynq tool as well. However, I prefer to get the queue info in the middleware so I will be able to do some extra stats by myself.

@ChristianYeah commented on GitHub (Sep 15, 2020): > github.com/hibiken/asynq/tools/asynq I'm using asynq v0.11.0 currently, and I installed the latest asynq tool as well. However, I prefer to get the queue info in the middleware so I will be able to do some extra stats by myself.

kerem commented

2026-03-15 19:05:43 +03:00

Author

Owner

@hibiken commented on GitHub (Sep 15, 2020):

You should be able to see which queues are being processed by running asynq.Server by running the following command.

asynq servers

But if you'd like to get a hold of queues that are being processed within your code, then I think we need to add a method to the Inspector type. Would that help?

Side Note: I recently released v0.12 which included a number of breaking changes Please see the release notes for upgrade info when you upgrade.

@hibiken commented on GitHub (Sep 15, 2020): You should be able to see which queues are being processed by running `asynq.Server` by running the following command. ```sh asynq servers ``` But if you'd like to get a hold of queues that are being processed within your code, then I think we need to add a method to the [`Inspector`](https://godoc.org/github.com/hibiken/asynq#Inspector) type. Would that help? **Side Note**: I recently released v0.12 which included a number of breaking changes Please see [the release notes](https://github.com/hibiken/asynq/releases/tag/v0.12.0) for upgrade info when you upgrade.

kerem commented

2026-03-15 19:05:48 +03:00

Author

Owner

@ChristianYeah commented on GitHub (Sep 15, 2020):

You should be able to see which queues are being processed by running asynq.Server by running the following command.
asynq servers
But if you'd like to get a hold of queues that are being processed within your code, then I think we need to add a method to the Inspector type. Would that help?

Side Note: I recently released v0.12 which included a number of breaking changes Please see the release notes for upgrade info when you upgrade.

that will be great. It's not urgent for me currently.

BTW, when I define the ErrorHandler during the server initialization according to the doc, It doesn't work as described in the comments
github.com/hibiken/asynq@82b6828f43/server.go (L101)

        // ErrorHandler handles errors returned by the task handler.
	//
	// HandleError is invoked only if the task handler returns a non-nil error.
	//
	// Example:
	// func reportError(task *asynq.Task, err error, retried, maxRetry int) {
	// 	   if retried >= maxRetry {
	//         err = fmt.Errorf("retry exhausted for task %s: %w", task.Type, err)
	// 	   }
	//     errorReportingService.Notify(err)
	// })
	//
	// ErrorHandler: asynq.ErrorHandlerFunc(reportError)

an error will raise,

Cannot convert expression of type 'func (task *asynq.Task, err error, retried int, maxRetry int)' to type 'ErrorHandlerFunc'

Thank you very much

@ChristianYeah commented on GitHub (Sep 15, 2020): > You should be able to see which queues are being processed by running `asynq.Server` by running the following command. > > ```shell > asynq servers > ``` > > But if you'd like to get a hold of queues that are being processed within your code, then I think we need to add a method to the [`Inspector`](https://godoc.org/github.com/hibiken/asynq#Inspector) type. Would that help? > > **Side Note**: I recently released v0.12 which included a number of breaking changes Please see [the release notes](https://github.com/hibiken/asynq/releases/tag/v0.12.0) for upgrade info when you upgrade. that will be great. It's not urgent for me currently. BTW, when I define the ErrorHandler during the server initialization according to the doc, It doesn't work as described in the comments https://github.com/hibiken/asynq/blob/82b6828f434904428225b90e9ff404bb133361e4/server.go#L101 ``` // ErrorHandler handles errors returned by the task handler. // // HandleError is invoked only if the task handler returns a non-nil error. // // Example: // func reportError(task *asynq.Task, err error, retried, maxRetry int) { // if retried >= maxRetry { // err = fmt.Errorf("retry exhausted for task %s: %w", task.Type, err) // } // errorReportingService.Notify(err) // }) // // ErrorHandler: asynq.ErrorHandlerFunc(reportError) ``` an error will raise, ``` Cannot convert expression of type 'func (task *asynq.Task, err error, retried int, maxRetry int)' to type 'ErrorHandlerFunc' ``` Thank you very much

kerem commented

2026-03-15 19:05:54 +03:00

Author

Owner

@hibiken commented on GitHub (Sep 15, 2020):

that will be great. It's not urgent for me currently.

Got it, I'll get to this issue in the next few weeks 👍
Let me make sure that I understood your ask correctly:
Do you need a list of queue names that are currently being processed by asynq.Server(s)?

Sorry about the ErrorHandler. The pacakge is still undergoing API changes from a version to another.
ErrorHandleFunc interface is now

type ErrorHandlerFunc func(ctx context.Context, task *Task, err error)

I'll fix the comment. Thanks for spotting.

Please let me know if you still having issues!

@hibiken commented on GitHub (Sep 15, 2020): > that will be great. It's not urgent for me currently. Got it, I'll get to this issue in the next few weeks 👍 Let me make sure that I understood your ask correctly: Do you need a list of queue names that are currently being processed by `asynq.Server`(s)? --- Sorry about the ErrorHandler. The pacakge is still undergoing API changes from a version to another. `ErrorHandleFunc` interface is now ``` type ErrorHandlerFunc func(ctx context.Context, task *Task, err error) ``` I'll fix the comment. Thanks for spotting. Please let me know if you still having issues!

kerem commented

2026-03-15 19:05:59 +03:00

Author

Owner

@ChristianYeah commented on GitHub (Sep 15, 2020):

queue

that will be great. It's not urgent for me currently.

Got it, I'll get to this issue in the next few weeks 👍
Let me make sure that I understood your ask correctly:
Do you need a list of queue names that are currently being processed by asynq.Server(s)?

Sorry about the ErrorHandler. The pacakge is still undergoing API changes from a version to another.
ErrorHandleFunc interface is now
type ErrorHandlerFunc func(ctx context.Context, task *Task, err error)
Please let me know if you still having issues!

I think the info from asynq tool is sufficient and I can pull the data from Redis for some simple customizations. :)

@ChristianYeah commented on GitHub (Sep 15, 2020): > queue > > that will be great. It's not urgent for me currently. > > Got it, I'll get to this issue in the next few weeks 👍 > Let me make sure that I understood your ask correctly: > Do you need a list of queue names that are currently being processed by `asynq.Server`(s)? > > Sorry about the ErrorHandler. The pacakge is still undergoing API changes from a version to another. > `ErrorHandleFunc` interface is now > > ``` > type ErrorHandlerFunc func(ctx context.Context, task *Task, err error) > ``` > > Please let me know if you still having issues! I think the info from asynq tool is sufficient and I can pull the data from Redis for some simple customizations. :)

kerem commented

2026-03-15 19:06:04 +03:00

Author

Owner

@hibiken commented on GitHub (Sep 15, 2020):

Sounds good! I'll keep this issue open so that if other people have the same ask, I'll revisit this 👍

@hibiken commented on GitHub (Sep 15, 2020): Sounds good! I'll keep this issue open so that if other people have the same ask, I'll revisit this 👍

kerem commented

2026-03-15 19:06:09 +03:00

Author

Owner

@ChristianYeah commented on GitHub (Sep 18, 2020):

@hibiken Hi, Ken.

In my project, I don't care about the retry, but the logging info.

currently, the Task struct has Payload attribute, and Payload's data is private

type Task struct {
	// Type indicates the type of task to be performed.
	Type string

	// Payload holds data needed to perform the task.
	Payload Payload
}

And the Payload has an attribute called data, which is private.

type Payload struct {
	data map[string]interface{}
}

In my project, I prefer to output the task payload into log directly rather than retring, so I can apply filebeats to servers as I can collect the log or the raw error payload & info by using ELK.

As the data prop is private, in order to minimize the side effect, I simply modify the source code to add a function to encode Payload into json.

function added below

func (p Payload) JsonPayload() (string, error) {
	data, err := json.Marshal(p.data)
	if y != nil {
		return "", err
	}
	return string(data), nil
}

Thank you.

@ChristianYeah commented on GitHub (Sep 18, 2020): @hibiken Hi, Ken. In my project, I don't care about the retry, but the logging info. currently, the Task struct has Payload attribute, and Payload's data is private ``` type Task struct { // Type indicates the type of task to be performed. Type string // Payload holds data needed to perform the task. Payload Payload } ``` And the Payload has an attribute called data, which is private. ``` type Payload struct { data map[string]interface{} } ``` In my project, I prefer to output the task payload into log directly rather than retring, so I can apply filebeats to servers as I can collect the log or the raw error payload & info by using ELK. As the data prop is private, in order to minimize the side effect, I simply modify the source code to add a function to encode Payload into json. function added below ``` func (p Payload) JsonPayload() (string, error) { data, err := json.Marshal(p.data) if y != nil { return "", err } return string(data), nil } ``` Thank you.

kerem commented

2026-03-15 19:06:14 +03:00

Author

Owner

@hibiken commented on GitHub (Sep 18, 2020):

I see. Thanks for this feedback!
It makes sense to have Payload implement fmt.Stringer interface.
I'll make that change soon.

@hibiken commented on GitHub (Sep 18, 2020): I see. Thanks for this feedback! It makes sense to have `Payload` implement [`fmt.Stringer`](https://golang.org/pkg/fmt/#Stringer) interface. I'll make that change soon.

kerem commented

2026-03-15 19:06:19 +03:00

Author

Owner

@hibiken commented on GitHub (Sep 20, 2020):

@ChristianYeah I've added String() and MarchalJSON() methods to Payload. I have a few more changes I want to include in the next version release, so the change hasn't been released yet. But feel free to fork the repo and use it until then!

Let me know if you have more feedback 👍

@hibiken commented on GitHub (Sep 20, 2020): @ChristianYeah I've added `String()` and `MarchalJSON()` methods to `Payload`. I have a few more changes I want to include in the next version release, so the change hasn't been released yet. But feel free to fork the repo and use it until then! Let me know if you have more feedback 👍

Rows
Columns

[GH-ISSUE #192] [FEATURE REQUEST] access to the real-executed queue name somewhere #2084