Quickstart
In five minutes you'll have a working scope, a queue inside it, one message published, one message claimed, and one message completed. This is the smallest possible useful ScaiQueue interaction.
You need:
- A ScaiGrid API key with
scaiqueue:manage,scaiqueue:publish, andscaiqueue:consume(any tenant admin has all three). curl, Python withhttpx, or Node — pick one of the blocks below.
1 2 | |
1. Create a scope#
A scope is a namespace for related queues. Creating one also auto-creates the system queues (_dead_letter, _events, _audit, _integrity, _corrections).
1 2 3 4 5 6 7 | |
1 2 3 4 5 6 7 8 | |
1 2 3 4 5 6 7 8 9 10 | |
Save the returned scope.id as SCOPE_ID.
2. Create a queue#
Queues live inside scopes. Each queue has an ordering mode (fifo, priority, or deadline) and a consumer mode (competing or broadcast). For most work distribution you want competing + fifo.
1 2 3 4 5 6 7 8 9 10 | |
1 2 3 4 5 6 7 8 9 10 11 | |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | |
Save queue.id as QUEUE_ID.
3. Publish a message#
Publishing writes a row in MariaDB and pushes the new message id into the queue's Redis pending sorted set. Use idempotency_key so retried publishes don't create duplicates. Labels and priority are optional but cheap to set early — routing rules consume both.
1 2 3 4 5 6 7 8 9 10 | |
1 2 3 4 5 6 7 8 9 10 11 12 | |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | |
The same idempotency_key published twice returns the original message id instead of creating a duplicate.
4. Claim a message#
Claim takes the next message off the queue and locks it for you. The lock lasts visibility_timeout_s — if you don't complete or fail the message within that window, the visibility-timeout enforcer puts it back as pending and another consumer can take it.
1 2 3 4 | |
The response is a list. Each claimed message includes the full body, the labels, and an attempts counter that ScaiQueue has already incremented. You have visibility_timeout_s seconds to call complete, fail, or extend — if you don't, the visibility-timeout enforcer returns it to pending and another consumer can claim it.
5. Complete the message#
Completion moves the message to its terminal state and frees the slot. Pass any structured result you want downstream consumers to read in the response field — it ends up on the message row and in the event payload.
1 2 3 4 | |
The message moves to completed, the queue's depth_claimed decrements, and a scaiqueue.message.completed event is published on ScaiGrid's internal event bus carrying the message's correlation_id — so any worker (or ScaiCore checkpoint resolver) waiting on this id can react without polling.
What just happened#
- The scope you created is a row in MariaDB. Five system queues were created alongside it.
- Each publish wrote a row in
mod_scaiqueue_messagesand added the message id to a per-queue Redis sorted set scored by ordering mode (created_at for FIFO, deadline for deadline, tier+score for priority). - The claim was a
ZPOPMINon that sorted set plus aSET NX EXclaim lock — atomic across consumers. - Completion released the Redis claim and decremented queue counters.
Next#
- Architecture — the publish, claim, complete, reclaim loop in detail.
- Topics, types, and HITL specs — what makes a queue typed.
- Build a pipeline with routing — multi-queue flow with routing rules.
- Add a human review step — HITL end-to-end.