coulomb/activity-core
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Repair production automation truth and schedule cleanup
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details
Build and Publish Container Image / build-and-push (push) Successful in 18s
Details

Browse source
This commit is contained in:
tegwick 2026-08-20 11:20:23 +02:00
parent 8bcb416285
commit 944fd158de
19 changed files with 441 additions and 64 deletions
Download patch file Download diff file Expand all files Collapse all files

17
docs/idempotency.md
View file

@ -24,15 +24,24 @@ produces at most one workflow execution.
A *misfire* occurs when a scheduled trigger fires after its nominal time because the
worker was down, overloaded, or the schedule was paused.
| Policy | `dedupe_key_strategy` value | Behaviour |
| Policy | `trigger.misfire_policy` value | Behaviour |
|---|---|---|
| Skip | `"skip"` | Missed runs are discarded. Temporal `ScheduleOverlapPolicy.SKIP`. |
| Catch up | `"catchup"` | Missed runs are replayed up to 10 times (configurable). Uses `schedule.handle.backfill()`. |
| Compress | `"compress"` | One run is executed with a widened context window covering all missed intervals. |
The `dedupe_key_strategy` on `ActivityDefinition` must match the `misfire_policy` on
`CronTriggerConfig`. They are separate fields to allow the schedule configuration
(how Temporal fires) to be decoupled from the workflow logic (how missed runs are handled).
`trigger.misfire_policy` is the runtime control. The persisted
`dedupe_key_strategy` field is legacy API/DB compatibility metadata; schedule
execution does not read it. In particular, `dedupe_key_strategy: skip` does
**not** suppress a later scheduled fire whose resolved context or emitted task
content matches an earlier fire. New definitions should configure only the
trigger policy and should not rely on `dedupe_key_strategy` for content
deduplication.
Each nominal cron time produces a different workflow ID. If an hourly rule sees
the same unread message on consecutive hours, both hours may emit work. That
requires an explicit domain idempotency key or consumer-side state transition;
it is not a Temporal misfire concern.
---