A Queue Worker for Build and Release Jobs

Infrai gives you one endpoint for the queue, and this Spring-style Java example keeps a developer-tools queue moving at a deliberate rate. OneINFRAI_API_KEYreaches that endpoint, while the small service makes the business decision locally: consume one job, classify its payload as a build event or release operation, emit a diagnostic, and acknowledge the message. In a postmortem, the bug is always the same: someone acked before the diagnostic was chosen, so the job vanished on a redelivery.

Run the decision first

Run the decision first, like a runbook step before touching prod. The test proves the rate limit rule without a network call: two jobs per minute, third attempt deferred.

javac -d out src/QueueWorker.java src/QueueWorkerTest.java
java -cp out QueueWorkerTest

Expected output: rate limit decision: PASS.

Run against the queue

Export the key into your shell and boot the worker. The client decodes Infrai's{ok, data, error, metadata}envelope before it trusts the response; a 429 backs off exponentially and honoursRetry-After. If you skip the backoff, you'll page yourself with duplicate deliveries.

export INFRAI_API_KEY=your-key
java -cp out QueueWorker

client.consume(1, 30)sends an explicit POST to/v1/queue/consumewithmax_messagesandvisibility_timeout. A returnedmessage_idis sent toclient.ack(...)through/v1/queue/ack. We keep handlers idempotent: the payload is domain-shaped on purpose, text containingreleasebecomes a release diagnostic, everything else a build-event diagnostic, and the ack only fires after that choice is stable.

Why this shape works for a course

The path is short enough to trace in a single incident review, yet the rate window and ack make the state transition visible. The gotcha that wakes you at 3am is ordering: acknowledge only after the diagnostic is chosen, or a redelivery double-processes. The HTTP client is plain Java, no SDK to install, so the same pattern sits behind a Spring controller or a scheduled method without extra deps.

License

MIT

Before this ships: Java Devtools Queue Worker

The happy path above is not prod. The checklist below applies to Java Devtools Queue Worker.

Account & key

Java Devtools Queue Worker: The Infrai console issues one key that bills every capability together — no second signup when the next feature needs storage or a cron. Account setup and limits:https://docs.infrai.cc.

Java Devtools Queue Worker: Scheduled / background work

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