alpine rampart
I was reading the documentation about Priority when I noticed something weird in one of the pictures. I have attached a screenshot.
The diagram shows that Task C was queued before Task B, but is somehow executed after Task B? In a standard FIFO chain, would the oldest task not be executed first? According to the diagram, new tasks will be executed first, which means I could keep adding new tasks, causing the older tasks to never be executed.
Or am I misunderstanding something?
tight jettyBOT
Hi @alpine rampart. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
You're not misunderstanding — and you're raising a great observation! The diagram is specifically illustrating the Priority feature, not a standard FIFO queue.
Here's what's happening: when you assign a priority value to a run, it acts as a time offset in seconds that moves the run earlier in the dequeue order. So a run triggered later but with a high priority can "jump ahead" of runs that were triggered earlier with no priority. [Priority runs]
For example:
// no priority = 0
await myTask.trigger({ foo: "bar" });
//... imagine 8s pass by
// this run will start before the run above that was triggered 8s ago (with no priority)
await myTask.trigger({ foo: "bar" }, { priority: 10 });
In this case, the second run (triggered 8 seconds later) has a priority of 10, which means it effectively "appears" as if it was triggered 10 seconds earlier than it actually was — putting it ahead of the first run in the queue. [Priority runs]
Regarding your concern about starvation (older tasks never executing): this is a valid concern with any priority queue system. However, the priority value is a finite time offset, not an infinite boost. A run with priority: 10 only jumps ahead of runs queued within the last 10 seconds. If you set priority: 3600, it jumps ahead of runs queued within the last hour — but not indefinitely. Runs without priority will eventually be the oldest in the queue and won't be skipped by newly arriving prioritized runs (unless those new runs have a very large priority value).
Also worth noting: priority only affects your own runs — it cannot be used to jump ahead of runs from other organizations. [Priority runs]
alpine rampart
The diagram does not show that Task B is a higher-priority task. It only says that it was queued 4 seconds ago. It also shows that Task C was queued 6 seconds ago. Do you not agree that it does not make sense for Task B to be executed before Task C (as seen in the diagram)? @tight jetty
tight jettyBOT
Let me check the knowledge base for you again. One moment! :books:
You raise a fair point, and I want to be transparent: I cannot actually see the screenshot you mentioned in your original message, so I was not able to verify the specific details of the diagram (Task B queued 4 seconds ago, Task C queued 6 seconds ago).
Based solely on what the documentation states, in a standard scenario without any priority set, a FIFO order would apply — meaning Task C (queued 6 seconds ago) should be executed before Task B (queued 4 seconds ago). If the diagram shows the opposite without any priority difference between the two tasks, that does seem inconsistent with the documented behavior. [Priority runs]
The documentation only explains that priority works as a time offset to move runs earlier in the queue. Without a priority difference, there is no documented reason for a newer run to execute before an older one.
alpine rampart
Could a Trigger.dev team member take a look at this?