Confirmation of expected behaviour with http task triggering

[vernal kettle]

I have a workflow where I trigger a task using http, ex https://api.trigger.dev/api/v1/helloworld

In the header, I have my account secret key.

When this task gets picked up, is there any limitation to what worker picks up the task? That is, if I have a local dev worker started with my secret key, is that the only worker that can pick up that task, or does that task request go into some more generic pool?

I feel like I’ve seen behaviour that indicates the latter (some other runner has picked up the request, not just my own). Oh, the other note is that it appeared that more than one worker picked up the same task. Is that possible?

[lament plover]

Hi @vernal kettle. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

---

Based on the knowledge sources, here’s what can be confirmed about your scenario:

When you trigger a task via HTTP (e.g., POST to <https://api.trigger.dev/api/v1/helloworld>) and include your account secret key in the header, the task is associated with the specific environment and project that the secret key belongs to. The secret key scopes API access to a specific environment in a project, and only workers connected to that environment (using the same secret key) should be able to pick up and execute the task. This is explicitly stated in the authentication documentation: “Secret key authentication scopes the API access to a specific environment in a project” (API keys, Authentication).

Regarding which worker picks up the task: the task is placed into a queue for execution, and any worker connected to that environment (using the same secret key) can pick up the task. If you have a local dev worker running with your secret key, it should be the only worker able to pick up tasks for that environment—unless you have other workers (local or cloud) also connected with the same secret key.

As for your observation that more than one worker picked up the same task: according to the documentation, a run represents a single instance of a task being executed, and each run should only be executed once. If a task is triggered with an idempotency key, duplicate triggers with the same key will not create multiple runs (Idempotency). There is no mention in the documentation of a single run being picked up by multiple workers simultaneously. If you are seeing the same task run executed more than once, it could be due to triggering the task multiple times (without an idempotency key), or possibly a misconfiguration.

In summary:

• Only workers connected to the same environment (using the same secret key) can pick up the task.
• A single run should only be executed by one worker.
• If you see multiple executions, check for duplicate triggers or missing idempotency keys.

If you continue to see unexpected behavior (like multiple workers executing the same run), it may be worth reaching out to Trigger.dev support, as this is not the expected documented behavior.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: