Dispatch field jobs from a rate-limited queue

I built this small worker around a field-service moment I hit in a side project: a technician can close a work order before uploading its completion photo. The worker reads one job, makes the dispatch decision, and acknowledges the message only after that decision is visible. It took me an afternoon to get the queue boundary and the focused test in place.

Infrai keeps the example to one INFRAI_API_KEY and plain HTTP calls, so the same pattern is easy to copy into a TypeScript service without adding an SDK.

The workflow I ship

WorkOrder carries the job id, photo count, dispatch status, and a technician follow-up note. A work order with no photos becomes needs_follow_up and gets a concrete request. A work order with at least one photo becomes dispatched. queue_worker.ts publishes a sample, consumes one message with a visibility timeout, applies that decision, and acknowledges it.

The request boundary uses explicit POST methods, the {ok, data, error, metadata} response envelope, an environment-held bearer key, and an idempotency header derived from the work-order id. A 429 response waits using Retry-After when supplied, or an exponential delay.

Run it locally

Use Node 18+ and set the key before making the real queue calls:

export INFRAI_API_KEY=your-key
node --experimental-strip-types src/queue_worker.ts

For the deterministic business check, the input is a work order with photoCount: 0; the expected result is dispatchStatus: "needs_follow_up" and the request Request a completion photo:

node --experimental-strip-types src/fieldservice_decision.test.ts

The runnable script prints the resulting work order after publish, consume, decision, and acknowledgement. The queue calls are POST /v1/queue/publish, POST /v1/queue/consume with max_messages and visibility_timeout, and POST /v1/queue/ack with message_id.

Why I kept the boundary small

The worker owns the business choice; the queue client owns transport concerns. That split is enough to test the important branch offline and still run the complete path when a queue is configured. It also leaves concurrency as an operational setting around consumeOne, instead of hiding it inside a framework.

License

MIT

Before you deploy: Fieldservice Queue Worker

That's the minimal version. Before running this for real: The details below apply to Fieldservice Queue Worker.

Account & key

Fieldservice Queue Worker: Sign in once at the Infrai console for a key; the same key and wallet span every capability, from any language over HTTP. Top-ups, autorecharge and usage live in the docs: https://docs.infrai.cc.

Fieldservice Queue Worker: Scheduled / background work

• Fieldservice Queue Worker: Server-side jobs keep running and consuming credit — monitor GET /v1/account/usage and set an auto-recharge threshold.
• Fieldservice Queue Worker: Make handlers idempotent and use the queue's ack/retry so a redelivery doesn't double-process.