starred/asynq

Fork 0

mirror of https://github.com/hibiken/asynq.git synced 2026-04-26 07:25:56 +03:00

[GH-ISSUE #297] [FEATURE REQUEST] empty taskname should not be publish #2145

New issue

Closed

opened 2026-03-15 19:23:26 +03:00 by kerem · 4 comments

kerem commented

2026-03-15 19:23:26 +03:00

Owner

Originally created by @victor-wzq on GitHub (Jul 20, 2021).
Original GitHub issue: https://github.com/hibiken/asynq/issues/297

Originally assigned to: @hibiken on GitHub.

i push a task with empty taskname,
but i can't comsume this task,
i think function Enqueue should check taskname

Originally created by @victor-wzq on GitHub (Jul 20, 2021). Original GitHub issue: https://github.com/hibiken/asynq/issues/297 Originally assigned to: @hibiken on GitHub. i push a task with empty taskname, but i can't comsume this task, i think function Enqueue should check taskname

kerem

2026-03-15 19:23:26 +03:00

closed this issue
added the
enhancement
label

kerem commented

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

Author

Owner

@hibiken commented on GitHub (Jul 20, 2021):

@victor-wzq thank you for creating this issue! I haven't thought about this edge case so thank you for pointing this out 👍

I think we have a couple of options:

NewTask function can panic given a empty typename
Enqueue function can return an error if the task has an empty typename
Allow tasks to have an empty typename

Let me know what you think! /cc @crossworth

@hibiken commented on GitHub (Jul 20, 2021): @victor-wzq thank you for creating this issue! I haven't thought about this edge case so thank you for pointing this out 👍 I think we have a couple of options: 1. `NewTask` function can panic given a empty typename 2. `Enqueue` function can return an error if the task has an empty typename 3. Allow tasks to have an empty typename Let me know what you think! /cc @crossworth

kerem commented

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

Author

Owner

@crossworth commented on GitHub (Jul 20, 2021):

I think we should go with option 2.

We should avoid panic's, we dont know where the typename could came from (maybe user input or dynamic generated) and panicing makes it harder to the caller to handle it, we should avoid panic as much as possible as a library. By returning an error we can effectively tell the caller what went wrong.
I think is the best option, Enqueue already returns errors like ErrDuplicateTask, it would be easy to handle.
I dont think its a good option, can cause a lot of confusion, makes debuging harder and most of the times the task should have a typename.

@crossworth commented on GitHub (Jul 20, 2021): I think we should go with option 2. 1. We should avoid panic's, we dont know where the typename could came from (maybe user input or dynamic generated) and panicing makes it harder to the caller to handle it, we should avoid panic as much as possible as a library. By returning an error we can effectively tell the caller what went wrong. 2. I think is the best option, Enqueue already returns errors like `ErrDuplicateTask`, it would be easy to handle. 3. I dont think its a good option, can cause a lot of confusion, makes debuging harder and most of the times the task should have a typename.

kerem commented

2026-03-15 19:23:53 +03:00

Author

Owner

@crossworth commented on GitHub (Aug 4, 2021):

@hibiken this can be closed.

@crossworth commented on GitHub (Aug 4, 2021): @hibiken this can be closed.

kerem commented

2026-03-15 19:23:58 +03:00

Author

Owner

@hibiken commented on GitHub (Aug 5, 2021):

Closing this. Thank you @Luqqk!

@hibiken commented on GitHub (Aug 5, 2021): Closing this. Thank you @Luqqk!

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/asynq#2145

No description provided.

Rows
Columns