Production Checklist

Each item below covers a failure that is straightforward to prevent before launch and difficult to diagnose afterwards.

Submitting tickets

• Ticket IDs are UUIDs generated in the game backend, and a timed-out CreateTicket is retried with the same ID.
• Everything the engine needs is in engine_input; everything the backend needs back is in metadata.
• Player.latencies uses host keys that map directly onto the provisioning layer’s placement identifiers.
• mmr values are on the same scale as the queue’s mmr_normalization_ref. The parameter defaults assume a normalised 0.0-1.0 range; a raw ladder rating in the thousands will dominate every other term until it is rescaled.
• The player is shown a queue state on the CreateTicket ack, not a match.

Consuming outcomes

• Outcomes are handled idempotently, keyed on Outcome.id or Match.id. Delivery is at-least-once on every sink.
• The outcome handler acknowledges quickly and provisions asynchronously. A handler that provisions before responding will hit the delivery timeout and cause a retry storm, with duplicate provisioning attempts as the visible symptom.
• ticket.expired and ticket.removed are handled as lists; both are batched.
• ticket.removed reasons are distinguished: re-queue for most, stop routing for QUEUE_RETIRED.

Honouring matches

• match.created is treated as a commitment: the integration either provisions a server or compensates with ReactivateTickets.
• The integration walks host.acceptable before declaring provisioning failed.
• terminal_retention_ttl_secs is set above the orchestrator’s worst-case provisioning time plus the fallback walk.
• A non-empty failed_ticket_ids from ReactivateTickets is alerted on, not ignored.

Error handling

• FAILED_PRECONDITION on CancelTicket is handled as “a match is coming”, and the match.created that follows is still honoured.
• UNAVAILABLE is retried with backoff rather than surfaced to the player.
• FAILED_PRECONDITION with x-ivk-reason: QUEUE_RETIRING stops further routing to that queue instead of being retried.

Configuration

• expiration_ttl_secs is slightly above the longest wait the game will display, so the timeout the player sees is the game’s decision.
• Credentials are loaded from a secret store, not from source control, configuration files, or a game client.
• If more than one ruleset is in use, fairness_weight reflects which mode is the headline one.

Backfill

• Backfill requests are cancelled when a match fills or ends.
• The launch plan does not depend on backfill being fulfilled. It is not yet implemented.