The re-evaluate and apply-rule pollers rescheduled on any non-terminal status, including 'pending'. The controllers seed a 'pending' entry before dispatch, so if the queue worker is down the job never runs, failed() never fires, and the client polls for the entire hour-long TTL with a spinner stuck at '0 of 0'. Give up after 30 consecutive 'pending' ticks (~30s at the 1s interval), mirroring the guard the AI-categorization poller already has. A long 'processing' run is unaffected — only a job that never leaves 'pending' trips the cap. |
||
|---|---|---|
| .. | ||
| css | ||
| js | ||
| views | ||