Expire Stale CometAPI Jobs Before Workers Spend on Them

Last reviewed: November 3, 2026 (Asia/Shanghai).

Direct answer

CometAPI queued job expiration should prevent stale work from reaching the API. Assign each job an immutable deadline when the application accepts it, then check that deadline again at the controlled dispatch point. Also check whether the job was canceled or its source revision was superseded. Expire ineligible work locally before creating a new billable attempt.

A queue can smooth traffic while preserving every request for later execution. After an outage, workers may therefore spend on summaries, alerts, or reports whose useful window has already closed. A concurrency limit controls how quickly that happens; a freshness decision determines whether the work should still happen.

Use broker message expiration as an additional filter. RabbitMQ’s Time-To-Live and Expiration guide documents retention limits and a delivery race in which a message can expire after being written to the socket. The application still needs a check near the outbound call.

Who this is for

This guide is for platform engineers and FinOps owners running queued CometAPI text jobs whose results lose value with age. It assumes the application owns job state and the dispatch path. RabbitMQ provides the concrete broker example; adapt the mechanism to your deployed broker and protocol.

Deadline selection, state transitions, and the checks below are implementation recommendations. No authenticated CometAPI request, billing experiment, or broker deployment was performed for this article. Mandatory archival or compliance work needs an explicit completion policy before anyone adds automatic expiration.

Key takeaways

Keep the original business deadline through retries, delays, and redelivery.
Check freshness after waiting for capacity and immediately before dispatch.
Distinguish an undispatched expired job from an uncertain model attempt.
Bound local prefetched work as well as the broker backlog.
Record estimated avoided exposure separately from actual spend and realized savings.

Contract details to verify

Define when a result stops being useful

For each workload, specify whether the deadline means latest permitted start or latest useful completion. A latest-start rule can admit a generation that finishes later. If completion time matters, require enough remaining time for a documented execution allowance and result handling. Such an allowance is a planning bound; measured latency cannot guarantee completion.

Keep a durable job record with these application fields:

Field	Purpose
`job_id` and workload scope	Stable identity and accountable owner
`accepted_at` and `expires_at`	Original acceptance time and immutable deadline
`deadline_semantics`	Latest start or latest useful completion
`source_revision`	Exact input version the job represents
`state` and ownership generation	Current eligibility and exclusive dispatch authority
`attempt_id`	Identity of an individual outbound attempt, when one exists
`estimate_revision`	Price and request assumptions used for financial admission

Use an authoritative clock and specify tolerated clock error. A delayed worker with an unreliable clock should defer to the authority before spending. Queue arrival time and retry time must not replace the original acceptance time.

For illustration, a job accepted at 10:00 with a latest-start deadline of 10:05 remains expired at 10:06 even if a retry queue received it at 10:04. A second transport delivery does not create another five minutes of business value. These times describe a hypothetical policy.

Configure the correct RabbitMQ expiration control

RabbitMQ distinguishes message TTL from queue expiration. Message TTL limits how long a message may remain in a queue. Queue expiration removes an unused queue; it does not express the deadline of each report or summary.

The TTL reference documents these AMQP 0-9-1 details:

A queue’s message-ttl policy or x-message-ttl argument uses milliseconds.
A publisher’s per-message expiration property uses a string representation of milliseconds.
When per-queue and per-message TTL both apply, the lower value wins.
Broker requeueing preserves the message’s original expiry time.
Expiration and physical removal can differ; expired messages can remain behind other messages and still appear in queue statistics.

When publishing a fresh transport message for an existing job, calculate TTL from its remaining lifetime. Do not republish with the original full duration. Keep the absolute application deadline in durable state because dead-letter handling and application retries can create new messages. If no lifetime remains, record the terminal decision without publishing work for execution.

Verify the deployed queue type, RabbitMQ version, client acknowledgement mode, and retry topology. The official pages served during research identify documentation version 4.4. Their behavior does not establish a feature of CometAPI itself.

Operator workflow

Put freshness at the dispatch boundary

Apply this sequence to one workload first:

At acceptance, authenticate the caller, create the stable job record, and apply the workload’s deadline policy. Bound backlog admission separately.
Publish a reference to that record using the remaining message TTL. Keep the request payload in its approved storage boundary.
On delivery, read authoritative job state. An already terminal job returns its recorded outcome without another model call. An uncertain prior attempt goes to reconciliation.
Wait for the applicable capacity permit, then reread eligibility. Time spent waiting consumes the same lifetime.
Through a serialized state transition, recheck deadline, cancellation, source revision, ownership, and budget eligibility. Grant one dispatch claim and reserve the permitted attempt’s exposure. Keep this operation short.
At the controlled outbound handoff, reject an expired dispatch authorization. Persist the attempt identity before handing the request to the HTTP client. A crash around that handoff leaves an uncertain attempt for reconciliation.
Record the result or durable hold, update the financial state, and then settle the broker delivery according to the application policy.

Every dispatcher must obey the same authority. A claim made before a long pause must not authorize a send indefinitely. Specify that the deadline check governs local handoff; it cannot prove the remote service received a request before that instant. Define whether cancellation can revoke an existing claim and expose the outcome. Cancellation or revision changes accepted after dispatch cannot retroactively prevent the call.

Use the existing atomic budget reservation design for the financial transaction. Integrate freshness into that admission decision. A separate unlocked deadline read followed by an unrestricted dispatch claim leaves a race with cancellation and competing workers.

CometAPI’s cost estimation guide combines model pricing with input size, output limits, or task counts. It treats the result as a budget guard and directs readers to actual usage and billing records afterward. Refresh an old queued job’s estimate against its approved request and pricing revision before admission. A job that is still useful can still exceed its permitted cost.

Handle delivery outcomes without recreating stale work

RabbitMQ’s acknowledgement reference explains that unacknowledged deliveries are requeued after their channel or connection closes. It also warns that immediate requeueing can create redelivery loops.

Persist an expired or canceled terminal decision before acknowledging a delivery. If the acknowledgement is lost, redelivery reads that terminal state and avoids dispatch. For an invalid job, durably record the rejection and use the approved quarantine or dead-letter path. Negative acknowledgement with requeue=false routes to a configured dead-letter exchange or discards the message; verify that behavior before relying on it.

For a transient capacity problem, delay only within the remaining lifetime. Preserve the job deadline and bound attempts. Once the deadline passes, stop recreating executable messages. A dead-letter consumer that republishes every expired item would defeat the control.

Broker expiration can remove a message before a worker sees it. Periodically reconcile durable queued records whose deadlines have elapsed. Mark them expired only after ruling out an existing dispatch claim; retain uncertain attempts for investigation. Queue depth alone cannot establish how many jobs expired or whether any API calls occurred.

Bound prefetch for push consumers using manual acknowledgements. The acknowledgement reference describes prefetch as limiting outstanding deliveries, with scope considerations, and notes that it does not affect basic.get polling. Workers must also bound their own buffers. A job already held by a consumer can become stale while waiting locally.

Keep expiration separate from cost settlement

Observed state	Freshness action	Financial treatment
Expired; dispatch never claimed	Record terminal expiration	No model attempt was started by this job
Reserved; proven never handed off	Revoke dispatch authority and expire	Release the reservation once dispatch is impossible
Dispatch may have occurred	Stop new attempts; reconcile the existing identity	Retain unresolved exposure
Response arrives after the useful deadline	Apply the documented result acceptance policy	Record the attempt’s usage regardless of result usefulness

An elapsed deadline does not establish that an upstream call was free or canceled. Retain uncertain commitments until evidence supports settlement or an approved accounting treatment. Releasing them solely because the queue entry expired can make the available budget look larger than it is.

Verification before rollout

Use a fake dispatcher and a controllable clock. The following are acceptance criteria, not reported test results:

Scenario	Required observation
Fresh job with capacity and budget	One authorized handoff and one attempt record
Undispatched job expires in the broker	Expiration is recorded or reconciled; no worker dispatch
Deadline passes in a local buffer or permit wait	Final check denies handoff
Retry or dead-letter replay arrives late	Original deadline remains effective
Cancellation races with dispatch claim	Serialization establishes which transition won
Two deliveries carry the same job ID	Existing state prevents a second unrestricted claim
Worker crashes around outbound handoff	Attempt remains uncertain; redelivery does not blindly resend
Late response contains usage	Cost is retained even if the result is discarded
Deadline or source revision is missing	Job is quarantined or held under the documented policy

During an outage-recovery exercise, verify that workers skip expired work before draining useful work through the approved concurrency controls . Check transport retries and local buffers, not only broker queue depth.

Failure modes

Every retry refreshes the TTL. Work stays executable indefinitely. Retain the absolute business deadline and derive each publication’s remaining duration from it.

Freshness is checked only on receipt. A worker passes the check and then waits for a permit. Recheck at the outbound handoff and expire short-lived dispatch authorizations.

Queue expiration is configured instead of message expiration. An active queue survives while old jobs keep flowing. Verify the exact TTL setting and preserve the application guard.

A stale result is labeled a zero-cost job. The API call already happened. Separate result acceptance, reported usage, calculated cost, and billing reconciliation.

Discard counts are presented as savings. Record expired-before-dispatch counts and their estimated exposure, with estimate revision. Those estimates are potential avoided model spend; realized savings require a defensible comparison and billing evidence. Broker, storage, and worker costs can remain.

Track opaque job and attempt IDs, queue age at dispatch, remaining lifetime, reason codes, ownership generation, and cost state. Use bounded workload labels in metrics. Keep prompts, generated content, and credentials out of shared cost logs.

Sources checked

Three primary public pages were retrieved on November 3, 2026, Asia/Shanghai:

CometAPI: Estimate request cost before calling a model — billing-unit estimates, output limits, task multipliers, and estimate-versus-actual treatment.
RabbitMQ: Time-To-Live and Expiration — message and queue expiration, TTL units, requeue behavior, removal timing, and the delivery race.
RabbitMQ: Consumer Acknowledgements and Publisher Confirms — manual acknowledgements, automatic requeueing, negative acknowledgements, redelivery loops, and prefetch limitations.

These currently served technical references support an evergreen engineering task. This article reports no pricing announcement or new product release. Recheck the broker version and selected CometAPI model’s billing contract before implementation.

FAQ

Is broker TTL enough to stop stale API spending?

It helps remove queued work, but application state and local waiting can change after delivery. Preserve the deadline and check it at the controlled handoff.

Can every workload discard old jobs?

No. An interactive summary may expire quickly, while required processing may need completion regardless of age. Define workload policy and escalation before enabling automatic discard.

Does an expired job cancel a CometAPI request already sent?

Expiration establishes local eligibility. It does not prove cancellation or zero usage for an existing attempt. Reconcile that attempt separately.

Should an operator extend deadlines after an outage?

Only through an explicit new decision about the work’s continuing value, source version, and budget. Retain the original job history rather than silently making a retry appear fresh.

Reader next step

Choose one queued summary or report. Define its deadline semantics, retain the original deadline across every retry path, and implement the local-buffer expiration test before enabling automatic discard. Require an auditable terminal outcome and zero handoffs for jobs that fail the final freshness check.

If you are setting up the route, Start with CometAPI , then apply the deadline and budget controls before connecting an unattended worker.