single job page view #598
single job page view #598
Conversation
|
Thank you for this PR.... It sounds to me as a filter on the requested queue, you can add a querystring which will make queue list return the specific job in the list... this way, you don't need to re-implement 80% of the code. Maybe this way will be a start of "queue filtering feature" WDYT? |
|
Interesting - to me a router pattern for |
|
Yeah, so I guess we can proceed with this... I'll need to review this PR more throughly ... |
| @@ -33,6 +33,8 @@ export interface QueueJob { | |||
| retry(state?: JobRetryStatus): Promise<void>; | |||
|
|
|||
| toJSON(): QueueJobJson; | |||
|
|
|||
| getState(): Promise<Status | 'stuck' | 'waiting-children' | 'unknown'>; | |||
There was a problem hiding this comment.
Apparently this is the full union of states 🤷♂️ - idk if this is going to cause problems, any advice here would be greatly appreciated.
There was a problem hiding this comment.
Why do you need to specify all of the statuses (which the board not supports yet, as far as i know, bull doesn't support waiting-children as well)
This interface must be a unify version between bullmq & bull
There was a problem hiding this comment.
I'm getting a build error unless I include them all.
https://gist.github.com/jamesgweber/cbf1e8bbf29f169964d37b6adb8c405a
bull board might not support it but { Job } from 'bull'; does and it expects that continuity
Another possible option is getState(): Promise<Status | any>; 🙅
| @@ -33,6 +33,8 @@ export interface QueueJob { | |||
| retry(state?: JobRetryStatus): Promise<void>; | |||
|
|
|||
| toJSON(): QueueJobJson; | |||
|
|
|||
| getState(): Promise<Status | 'stuck' | 'waiting-children' | 'unknown'>; | |||
There was a problem hiding this comment.
Why do you need to specify all of the statuses (which the board not supports yet, as far as i know, bull doesn't support waiting-children as well)
This interface must be a unify version between bullmq & bull
|
Hi @jamesgweber I didn't forget about this PR... Will review it asap |
|
|
||
| useInterval(() => { | ||
| fetchJob(); | ||
| }, 5000); |
There was a problem hiding this comment.
should use users config of interval time
Do we pause the interval of the QueuePage?
There was a problem hiding this comment.
should use users config of interval time
idk what this means - if you can point me to an example I'm happy to make the change
Do we pause the interval of the QueuePage?
no - I just let the polling continue because it keeps everything in sync and it's simple. traffic is not a real concern for an app like this imo. You probably wouldn't have 1000s of concurrent users.
|
Hi @jamesgweber I've reviewed the code, it looks OK. After requested changes, I will approve this PR, and will make several refactors to solve this issue (basically break down the useStore hook into small parts) Thank you for your patience, and sorry for the delay 🙏🏼 |
|
Thank you @felixmosh - we appreciate your work |
|
Thank you for the PR |
Greetings - my team is using bull-board for a project and the need arose for having the ability to deep link into a failed job.
This is meant to be a first pass to see what you think & get some feedback. It lacks completeness as I still don't totally understand all the interaction patterns for paused / delayed jobs but I feel its headed in the right direction.