Statuses
Statuses
Use this page as shared source of truth for operator-facing status values.
Operator users
These values appear on user and simulator-user records.
| Status | Meaning |
|---|---|
active | User can use the Mini App. |
suspended | User is temporarily blocked. |
disabled | User is disabled. |
Staff memberships
These values appear on dashboard staff memberships.
| Status | Meaning |
|---|---|
active | Staff member can sign in if account status is also active. |
disabled | Staff membership is disabled for this operator. |
Orders and trades
These values appear in trade and order reporting.
| Status | Meaning |
|---|---|
queued | Accepted, not yet actively processing. |
processing | OpenPoly processing in progress. |
operator_debit_pending | Debit request to operator wallet still pending. |
operator_debited | Debit succeeded. Downstream completion still running. |
operator_credit_pending | Credit request to operator wallet still pending. |
processed | Flow completed successfully. |
failed | Flow ended in failure state. |
compensation_pending | Reversal or compensation still required. |
compensated | Compensation completed. |
manual_review | Automatic flow stopped. Operator or Polynion review required. |
Redemptions
Redemption list uses same lifecycle family, with emphasis on payout-side work.
| Status | Meaning |
|---|---|
queued | Redemption accepted, not yet processing. |
processing | Redemption logic running. |
operator_credit_pending | Operator wallet credit still pending or unresolved. |
processed | Redemption completed successfully. |
failed | Redemption failed. |
manual_review | Human follow-up required. |
Balance operations
These values describe operator wallet mutation records.
| Status | Meaning |
|---|---|
planned | Operation created, not sent yet. |
sent | Request sent to operator wallet service. |
succeeded | Operator wallet confirmed success. |
failed | Operator wallet confirmed failure. |
unknown | Final result unclear, usually timeout or ambiguous remote result. |
retrying | OpenPoly is retrying or re-checking operation state. |
manual_review | Automatic recovery not enough. Human review required. |
Balance operation directions
debitcreditdebit_reversalcredit_reversal
Polyflight product and money lifecycles
Product status:
| Status | Meaning |
|---|---|
disabled | Product is unavailable. |
enabled | New eligible purchases may be admitted. |
purchases_suspended | New admission is stopped; existing payout/loss-acknowledgement/refund/compensation delivery and reads continue. |
Purchase wallet lifecycle:
plannedsentsucceededfailedunknownmanual_reviewcompensation_pendingcompensated
Payment obligations use owed, in_flight, paid, or manual_review. Ticket result and payment status are separate: a won ticket may remain owed, and a cancelled ticket may remain refund payable. Newly settled losses use effect loss with amount 0; their statuses describe result-acknowledgement delivery only (paid means acknowledged, not money paid). The ticket stays lost in every delivery state, and unresolved loss delivery does not block flight financial settlement. No historical loss backfill or loss payout pending/processed callback is introduced.
Webhook outbox events
| Status | Meaning |
|---|---|
pending | Event exists, not dispatched yet. |
dispatching | Dispatcher currently processing event. |
dispatched | Event dispatch cycle completed for current endpoints. |
failed | At least one delivery still failing and eligible for retry. |
dead_letter | Delivery retries exhausted or terminally failed. |
Webhook deliveries
| Status | Meaning |
|---|---|
pending | Delivery record exists, no successful send yet. |
sent | Endpoint returned 2xx. |
failed | Attempt failed and next retry still possible. |
dead_letter | Retry window exhausted or delivery marked terminal. |
Simulator operations
These values describe simulator wallet operation records.
| Status | Meaning |
|---|---|
succeeded | Simulator operation applied. |
failed | Simulator operation failed. |
pending | Simulator operation exists but is not finalized. |
Operator action guidance
manual_review-> inspect logs, dashboard records, wallet operation evidenceunknown-> inspect the original idempotency key and wallet ledger manually; never replay primary money movement with a new keydead_letter-> fix receiver or config first, then replayfailedon webhook delivery -> check last status code and response sample