A crypto workflow should deduplicate triggers by mapping each source occurrence to one durable run before any branch starts. Retries must resolve to that run, while distinct candles, intended destinations and authorized reruns remain distinguishable. Trigger deduplication limits duplicate evaluations; it does not authenticate a webhook or guarantee that exchange orders execute once.
Count runs before counting orders
One trigger may start an AI analysis branch, a deterministic signal branch and a journal branch. If the same occurrence starts four runs, each branch can evaluate four times before an execution control notices anything wrong. Extra model calls, competing decisions and repeated notifications remain problems even if a later order check blocks additional trades.
Repeated delivery is normal for some providers. TradingView's webhook resubmission policy specifies a resend after five seconds for HTTP 500–599 responses except 504, with up to three resends. That permits four sends for one trigger under that policy; it does not describe every failure or provider.
The admission question is therefore: “Has this occurrence already been assigned a run for this destination?” Ask it before fan-out, meaning the point where one run splits into several branches. A valid answer can be an existing run that completed without trading.
Define the identity boundary
Keep three identities separate: the occurrence, each delivery attempt and the run admitted for a particular workflow destination. An attempt's arrival time changes on retry. A run ID generated afresh for every arrival also changes. Neither alone identifies the repeated occurrence.
The CloudEvents 1.0.2 event specification provides a useful model: producers make the combination of source and event ID unique for distinct events, and consumers may regard identical source and ID values as duplicates. This is an event-format convention, not evidence that a particular chart alert implements it or always preserves an ID across retries.
For a sender with a reliable stable ID, bind that identity to a trusted workflow destination and environment. One event may legitimately feed two subscribed workflows, each receiving its own run. A retry addressed to the same subscription should retrieve the same run.
When no stable ID exists, define an occurrence key from documented source semantics. For a candle trigger, that could include venue, product, instrument, interval, interval anchor, candle opening timestamp and trigger rule identity. Use the candle-close trigger contract to establish those fields. “BTC buy” or a rounded arrival minute cannot distinguish separate legitimate signals.
A payload hash is useful conflict evidence but a poor universal identity. Whitespace can change without changing meaning, and identical payloads can represent separate scheduled occurrences. Define which fields are immutable and how their comparable representation is constructed.
Fill out a run-admission worksheet
This worksheet describes a design to evaluate, not a list of KLINEO configuration controls.
| Item | Illustrative choice | Required interpretation |
|---|---|---|
| Occurrence identity | Source S, event A | One upstream occurrence, independent of delivery attempts |
| Destination scope | Subscription W, paper environment | One admitted evaluation for this subscription; live is a separate authorized destination |
| Stable admission lookup | Destination scope plus occurrence identity | Locate the existing run before selecting new execution work |
| Frozen run context | Workflow revision 7 and saved input references | Redelivery preserves the context selected at first admission |
| Immutable-content digest | Digest of specified occurrence fields | Same identity with changed content is a conflict to investigate |
| Run outcome | Pending, running, completed, skipped or failed | A failed or skipped run still belongs to its original occurrence |
| Branch launch identity | Run ID plus branch slot | Recovery finds missing branch work without starting a fresh run |
| Recovery and retention | Recorded policy and expiry boundaries | Late deliveries have an explicit outcome after normal processing ends |
Keep revision selection out of a lookup that would turn every deployment into a new occurrence. If event A was admitted under revision 7, redelivery after revision 8 is deployed should find A's original run. Store the chosen revision on that run. Applying revision 8 to historical data is a separately authorized research rerun, linked to the original occurrence.
Four deliveries, three branches
Consider a hypothetical workflow with exactly three branch slots: analysis, signal and journal. Event A arrives four times because of redelivery. Event B is the next distinct candle. Both are addressed to the same paper subscription. The following outcomes are design expectations, not measured platform behavior.
| Arrival or recovery case | Run-admission result | New logical branch launches |
|---|---|---|
| First A delivery | Create run R-A with its frozen context | Three |
| Concurrent second A delivery | Retrieve R-A after the atomic admission decision | Zero |
| Third A delivery after completion | Reference R-A and its recorded outcome | Zero |
| Fourth A delivery after restart | Recover R-A from durable storage | Zero |
| First B delivery | Create distinct run R-B | Three |
| A identity with changed immutable signal fields | Flag a conflict; preserve R-A | Zero |
| Worker resumes R-A after two branch slots were recorded | Schedule the missing slot under R-A | One missing slot; no new run |
Without admission deduplication, four A deliveries could create 4 × 3 = 12 logical branch launches. With the worksheet's rule, A creates three. Adding B brings the total to 3 + 3 = 6, rather than 12 + 3 = 15. The recovery row completes A's existing set of three; it does not add a fourth slot. Worker attempts may still exceed logical launches, so branch operations need their own retry rules.
This controls cardinality, not capital. If multiple accepted branches can change exposure, branch risk budgets determine how their permitted commitments interact. One admitted run can still contain several independent trading actions.
Make admission and launch recoverable
A separate “does this exist?” read followed by an insert allows two arrivals to both observe absence. Use a shared uniqueness boundary. For example, PostgreSQL's INSERT documentation explains how a unique constraint or index can arbitrate conflicting inserts, with ON CONFLICT DO NOTHING avoiding the duplicate insertion. Only a successful new admission should create a new run.
Persist the accepted identity, run and pending launch work together where the storage design permits. Otherwise, document how recovery detects the gap. Marking an occurrence accepted and then crashing before queuing its branches can silently lose the run. Queuing branches first and recording admission later can multiply them.
A durable pending-work record can let recovery schedule unfinished branch slots. Queue delivery may itself repeat; each branch must recognize its run and slot rather than assume one delivery. See safe branch merging for how downstream joins account for branch completion. A completion counter alone is unsafe if repeated messages increment it twice.
Cases that must stay separate
Two source IDs reporting the same market condition are not automatically duplicates. They may describe different markets, observation times or definitions. Only coalesce them when an explicit upstream mapping proves they represent the same occurrence under the workflow's policy. Otherwise evaluate their meanings using the contradictory-source worksheet; identity matching cannot settle factual disagreement.
Likewise, admission is separate from the security checks in webhook replay protection. A unique event can be unauthenticated or stale. A duplicate with a valid signature still belongs to its previous run. Do not erase accepted identities merely to make an old signal appear new.
Finally, a failed branch must not authorize a fresh whole-workflow run that repeats completed actions. An exchange submission with an unknown result needs the order idempotency and recovery rules attached to that action. Deduplicating triggers cannot resolve whether an order already traded.
Check the admission record under failure
Test two simultaneous copies, a restart after admission but before launch, repeated queue deliveries, a deployment between retries, changed content under the same ID and a legitimate new candle with identical values. Also test arrival after the retention boundary. A short-lived cache can admit an old occurrence as new after eviction; retain evidence for the supported redelivery horizon and define what happens outside it.
For each test, inspect the number of admitted runs, frozen revisions, logical branch slots and recorded duplicate reasons. Include skipped runs in the counts. Use an isolated harness or an available paper environment; paper validation explains why simulated execution evidence has limits. The acceptance target is an explainable run history, including deliberate reruns and unresolved failures.
This AI-assisted educational article follows the editorial policy. Primary sources were reviewed on October 23, 2026. The worksheet is a proposed architecture and does not establish that KLINEO exposes or implements its admission controls.