Core Module 2.3.0 - Enhanced Workflow Stability and Event Reliability

• The first reduces the probability that two re-sourcing attempts execute at the same time
• The second ensures that even when they do, only one set of fulfillments is persisted

How It Works at a glance

• Stagger Concurrent Attempts with Two Scheduled Events
  Rather than triggering re-sourcing immediately when a fulfillment expires, the `ReSourceOrder` ruleset schedules two `SourceOrder` events with different configurable randomized delays:
  • The first event fires with a base delay of approximately 30 seconds, with a random offset applied around that value. When two fulfillments expire at the same time, the randomization makes it likely that their re-sourcing attempts will land in different execution windows. If the first attempt completes before the second begins, the second finds no unfulfilled items remaining and exits cleanly
  • The second event fires approximately 5 minutes after expiry. By that point, all in-flight attempts from the original expiry wave have either succeeded or failed. Any items that remain unfulfilled are picked up and processed. In the large majority of cases, this event fires, finds nothing to do, and exits. Its value lies in the edge cases where it is the only path to recovery
  • The two events serve distinct purposes:
    • the first reduces the probability of concurrent execution
    • the second provides a self-correcting fallback for the rare cases where the first is not sufficient
• Deduplicate at the Database Level Using Deterministic References
  Scheduling alone reduces but does not eliminate the risk of concurrent execution. To handle the cases where two attempts do run simultaneously and both reach fulfillment creation, fulfillments in the reference workflow are assigned deterministic, index-based references rather than random identifiers. When two concurrent attempts start from the same loaded order state - meaning the same number of existing fulfillments - they calculate identical references for the new fulfillments they are about to create.
  
  When the `fc.api.fulfilment.uniqueness` setting is configured to `REF_ONLY`, the fulfillment's external reference is copied to its `unique_reference` field before persistence. A database-level unique constraint on the combination of order and unique reference then ensures that only one of the concurrent attempts can persist its records. The second attempt's identical references are rejected at the database level - no duplicate fulfillments are created, and no additional inventory is reserved.
• This Pattern Applies Only to Fulfillment Expiry Re-Sourcing
  The `ReSourceOrder` ruleset and the `ScheduleEventWithRandomOffset` pattern are applied exclusively to the re-sourcing flow triggered by fulfillment expiry. All other sourcing entry points - initial sourcing at order creation, partial fulfillment sourcing, and sourcing triggered by rejection and reassignment - route directly to `SourceOrder`.
  
  Initial sourcing does not face the same concurrency risk. For CC and HD orders, a single sourcing event is triggered per order. For Multi orders, sourcing is triggered once per fulfillment choice. In both cases, there is no competing parallel execution path that would produce the same race condition.

Required Configuration

• The delay reduces the likelihood of concurrent execution
• The uniqueness constraint handles the cases where concurrent execution still occurs

Intended Use