Crypto workflow queued signal expiry should preserve a deadline tied to the original signal and enforce it when a worker takes the job and again immediately before an order attempt. Time spent waiting, retrying or awaiting approval consumes the same validity window. A free worker, a new delivery or a fresh API signature must not renew an old entry; a newer signal may also make it ineligible under an explicit supersession rule.
Define what expires and when its clock starts
An entry candidate can be valid when created and obsolete when capacity becomes available. A queue preserves work; it cannot establish that the work remains worth acting on. The expiry policy needs a named action boundary: latest analysis start, latest order submission or another precisely defined milestone.
This article uses a latest-submission deadline for an entry. Research may finish after that deadline for audit purposes, but it cannot authorize the expired entry. These are reference design choices, not a claim about available KLINEO settings.
Choose the start from the signal's meaning. A rule based on a completed candle might use its verified close boundary. A rule based on a discrete market event might use that event's documented time. Starting the validity clock at local enqueueing silently excludes the delay before the message reached the queue.
The trading latency budget explains how to select and measure the full path. Here the narrower task is preserving that chosen deadline through delayed jobs. Store the source-time definition, unit, expiry instant and policy revision alongside the signal. Treat those fields as trusted decision context, not a sender-controlled instruction to extend its own validity.
Broker timers answer different questions
Queue terminology can conceal several independent clocks:
| Clock or control | What it governs | What it does not establish |
|---|---|---|
| Signal validity deadline | Whether this candidate may still reach its named action boundary | That account and risk checks passed |
| Message retention | How long the broker retains a message | That its market evidence remains current |
| Delivery delay | When the message first becomes available | A guarantee it will start at that instant |
| Visibility or delivery lease | When another consumer may receive uncompleted work | An extension of the signal's deadline |
| Processing timeout | How long an attempt may run | Permission to submit after signal expiry |
For example, Amazon SQS queue parameters define retention, delivery delay and visibility timeout separately. None is an application assessment of a trading signal's age. Extending a processing lease can keep ownership stable while the candidate itself becomes ineligible.
RabbitMQ's TTL documentation defines message TTL around residence in a queue and preserves original expiry on requeue. It also documents a race in which expiration happens after a message is written to the socket but before it reaches the consumer. Broker expiry therefore complements application checks; it cannot cover all work after delivery.
An engine can offer another admission check. Celery's task expiration documentation supports seconds after publication or an absolute datetime, and says a worker receiving an expired task marks it revoked. That is a Celery behavior. A workflow still needs its own policy for a candidate that was eligible on receipt and ages during analysis.
Carry one deadline through every handoff
Persist an absolute expiry instant in the authoritative signal record. Each queue message should identify that record and its intended action, with a deadline copy useful for routing. If copies conflict, reject or resolve them against the authority; do not choose whichever gives more time.
At dequeue, reject an expired candidate before spending ordinary analysis capacity. Immediately before submission, check the same expiry again. Required approval, balance refreshes, risk checks, rate-limit waits and gateway queues all consume the remaining time. If the last dispatcher can hold a request, it must receive and enforce the deadline too.
Define the boundary explicitly: in the examples here, submission is eligible only when current time is strictly earlier than expiry. Equality fails. Cross-host age comparisons need compatible timestamps and a clock-uncertainty policy. If the plausible signal age reaches the limit once uncertainty is included, a conservative gate withholds the entry. The wall-clock and monotonic-clock guide covers the clock mechanics; a persisted process-relative timer is not a portable deadline after restart.
Retrying or restoring a run must reload the original expiry. Workflow checkpoint recovery is the relevant next step when the worker crashes: restoring progress must preserve decision constraints as well as completed work. A replacement worker cannot gain another validity window by receiving the same signal later.
A job passes dequeue and still expires before submission
Consider this hypothetical timeline. The source event is at 12:00:00.000 UTC and the entry has an invented five-second latest-submission window. Its absolute expiry is 12:00:05.000. Assume synchronized clocks without uncertainty for this fixture; the values are neither measured performance nor recommended trading thresholds.
| Observation | UTC time | Age from source event | Decision |
|---|---|---|---|
| Received and enqueued | 12:00:00.200 | 0.200 seconds | Preserve the 12:00:05.000 deadline |
| Worker takes the job | 12:00:03.400 | 3.400 seconds | Pass dequeue check; 1.600 seconds remain |
| Analysis and account checks finish | 12:00:04.600 | 4.600 seconds | Candidate still has 0.400 seconds |
| Gateway becomes ready to send | 12:00:05.100 | 5.100 seconds | Fail final check; submit nothing |
| Original job is redelivered | 12:00:07.000 | 7.000 seconds | Record expiry; do not restart the entry |
The measured queue wait is 3.400 − 0.200 = 3.200 seconds. It is smaller than the signal's 3.400-second age at dequeue. Later work consumes 5.100 − 3.400 = 1.700 seconds, exceeding the remaining 1.600 seconds by 0.100 seconds. The expected number of entry submissions is zero.
A five-second broker TTL starting at enqueueing would end at 12:00:05.200, already 0.200 seconds later than the signal's actual deadline. Republishing at 12:00:07.000 with another full five seconds would create an erroneous 12:00:12.000 deadline. Neither operation makes the underlying event newer.
An AI branch may retrieve useful evidence near the end of the window. Retrieval relevance ranking helps select that evidence, but its relevance and recent retrieval do not renew the original candidate. A fresh decision requires current observations and a deliberately reassessed candidate, linked to the old record.
Supersession needs a decision scope
Expiry asks whether enough time remains. Supersession asks whether a newer accepted decision has replaced this one. A candidate can fail either check independently.
Suppose a strategy allows one replaceable entry snapshot for a particular account, environment, instrument and position side. Candidate generation 81 has not expired, but generation 82 becomes the accepted current snapshot. Under that declared policy, 81 is superseded and cannot submit. Generation numbers here are illustrative application versions, not exchange order identifiers.
Define that replacement scope carefully. Grouping everything by ticker could discard a protective exit because a new entry arrived. Independent strategies or accounts may need independent decisions. Preserve cleanup and exposure-management work under their own policies rather than applying an entry freshness filter to every queue.
“Last received wins” is insufficient when an old source event arrives late. Validate the source's sequence or event boundary and define a tie/conflict rule before assigning the current generation. Do not grant stale observations precedence solely because the network delivered them last.
The current-generation check also needs a shared ordering rule. Two workers can both read an old current value before either submits. A shared dispatcher should order replacement acceptance and final dispatch admission for that scope. Specify which wins when those operations compete, and retain the version observed by the winner. If a gateway queues the admitted request, enforce its deadline and applicable replacement rule there too. Document the final supersession cutoff: a database comparison alone is not atomic with an external exchange request.
This differs from trigger deduplication, which asks whether the same occurrence already has a run. Two unique occurrences can legitimately exist while the newer one supersedes the older entry. It also differs from workflow cancellation, which withdraws a run's permission and manages its remaining obligations.
Expiry cannot undo an attempted order
The final check belongs before the write attempt. If the request has already left the dispatcher, passing the local deadline does not prove rejection, cancellation or absence of fills. Keep the original action identity and use order timeout reconciliation if the outcome is unknown.
Distinguish an expired, never-attempted candidate from an attempted action awaiting recovery. Replaying an audit message about the latter should recover its status, not submit a replacement entry. Likewise, a completed analysis may be retained without being eligible to advance to execution.
If expiry occurs before any attempt, record a terminal skipped outcome and settle the queue delivery under the broker's supported procedure. Preserve the reason and timing in durable history. Repeatedly returning the same expired job to the active queue wastes capacity and obscures whether a later worker actually found new evidence.
Validate the deadline under deliberate delays
Use an isolated harness with a controllable clock and a recorded submission counter. The following acceptance cases test the lifecycle, rather than the speed of a quiet system:
| Injected condition | Expected evidence |
|---|---|
| Job claimed exactly at expiry | Rejected; no ordinary analysis continuation |
| Analysis starts before expiry and finishes after it | Retained result; zero entry submissions |
| Worker restarts or job is republished | Original deadline survives |
| A newer accepted generation arrives first | Older candidate records supersession |
| An older source event arrives last | It cannot win merely through arrival order |
| Submission was attempted before a crash | Recovery inspects that action; no new entry attempt from expiry handling |
For each case, retain source time, enqueue time, dequeue time, final gate time, current generation and outcome reason. Report expired-at-dequeue, expired-before-send, superseded and unresolved-attempt counts separately. Queue depth alone cannot explain why useful work was lost.
Start with one delayed candidate and prove that its deadline survives every handoff. Then prove that no queue redelivery, worker restart or newer approval can turn its skipped entry into permission to submit.