Skip to main content

End-to-end flows

Each page in this section follows one kind of action from its trigger to a verified ESPN result. Every flow shares the lifecycle below. The flow pages cover what differs: the trigger, the queue, the keys and the checks.

FlowTriggerQueueHuman approval?
LineupTuesday optimizer, UI, rumor actionslineup_updatesNo
Waivers and IRTuesday waiver evaluator, UI, rumor actionswaiver_actions (plus lineup_updates for IR)No. IR + add is off unless AUTO_PUBLISH_IR_MOVES is on.
Outgoing tradesWednesday and Friday trade scantrade_submissionsYes, per offer
Incoming tradesTrade inbox refresh every 2 htrade_responses, trade_negotiationsYes, per response
Draft dayESPN draft room picksdraft_targetsOptional: pause, or turn off auto-publish

What does every action go through?​

StageWhat happensWhere to read more
TriggerA CronJob, the UI or another service calls core. Callers send an idempotency key.Queue publishing
RecordCore saves the action, the message and the decision evidence in one transaction. A repeat key returns duplicate with the original tracking_id.Activity submissions
PublishLineup, waiver and draft messages go through the outbox, which the activity runner retries if the broker was down. Trade messages are claimed in execution_log first, then published directly.Queue publishing
ExecuteKEDA starts a worker Job. The worker claims the tracking_id, so two pods can't run the same action.How bots run
VerifyThe worker re-reads ESPN and records the outcome.How do I know a write worked?
tip
A 202 is not an ESPN change

queued or approved means core handed the message to RabbitMQ. Only the worker's outcome, verified_complete or awaiting_processing, says something changed on ESPN.

Which outcome means what?​

The worker writes one of these to activity_actions.outcome. A failed execution, such as a PermanentError or a stop for manual verification, shows separately as execution state failed.