Reward Rescue

ReferralTrack gives each reward row only one active delivery owner across servers. A successful claim receives a unique ownership token; completion or safe release is accepted only from that exact attempt. This prevents a delayed callback from an older server process from changing a newer claim.

Vault deposits and console commands cannot participate in the database transaction. If a server stops after an external action but before database completion, ReferralTrack preserves the row as STUCK. It does not automatically retry that row because doing so could duplicate money, items or commands.

Commands #

• /referraltrack rescue or /referraltrack rescue list shows aged PENDING and STUCK rows.
• /referraltrack rescue retry <id> confirm <reason> returns an old STUCK row to the queue when its attempt count is below the configured maximum.
• /referraltrack rescue cancel <id> confirm <reason> permanently cancels an aged queued or stuck row.

The sender needs referraltrack.admin and the permission configured at reward-rescue.permission (default referraltrack.admin.rescue). Every successful mutation stores the reward ID, actor, action, reason and timestamp in the rescue audit table.

Safe operating procedure #

Before retrying a stuck row, confirm that the server which owned the failed attempt is stopped or healthy and that its economy/command effects did not occur. If delivery cannot be proven absent, cancel the row and reconcile the player's account manually. Never reduce stuck-age-minutes merely to force a faster retry during a lag or database outage.

pending-age-minutes only controls when queued rows appear as health findings. stuck-age-minutes controls when an incomplete processing attempt becomes eligible for staff action. maximum-manual-attempts is a hard retry ceiling, and list-limit bounds command output.