Pular para o conteúdo principal

O que o host controla

Saber onde está a linha evita que você projete em volta de algo que não pode mudar, e que depure algo que não é seu.

Seu​

Onde
Batalhas e assentosA API
O seu webhook de resultadoConsole → Configurações → Webhook
As suas credenciais de provedorConsole → Configurações → SoftSwiss
A sua allowlist de jogosConsole, se você tiver acesso; senão peça
Os seus usuários de console e os papéis delesConsole
As suas chaves de APIConsole, se tiver apikeys.write; senão peça

Do host​

Por que não é seu
A chave de assinatura de viewerUma chave assina para todo casino da instância. Rotacioná-la afeta todo mundo, então é só de super-usuário
As três janelas de lobbyEscopo de plataforma. Elas descrevem como a instalação roda uma batalha, não as credenciais de um casino
Capacidade de gravaçãoCompartilhada. O seu pico compete com o de todo mundo
Momento das atualizaçõesO cronograma de deploy deles
Configuração de e-mailDa instância inteira. É resolvida no boot e não pode ser por casino
O domínio do consoleO cookie de sessão é SameSite=Strict, então console e API precisam compartilhar um domínio registrável. Isso é decidido pelo DNS do host

O que isso significa na prática​

Você não pode ter uma janela de lobby diferente. Se o seu produto quer lobbies abertos por uma hora e a plataforma roda dez minutos, isso é uma conversa com o host, não uma configuração. Projete a sua UI em torno dos valores deles, e peça esses valores logo.

Uma rotação de chave de assinatura é invisível se bem conduzida. O host nomeia uma chave nova e deixa a antiga verificando até se aposentar, então tokens já nos browsers continuam funcionando. Espectadores tomando 401 no socket de repente significa que a rotação foi feita sem janela, o que é problema do host; reemitir é a sua mitigação.

A capacidade é compartilhada. 503 unavailable significa que a instância está no teto de batalhas em voo, que pode ser tráfego de outra pessoa. Retente com backoff e jitter, e leve ao host se virar rotina.

Atualizações podem falhar batalhas em voo. Uma batalha no meio da gravação depende de gravadores já rodando, então batalhas em voo podem terminar como battle.failed quando o host faz deploy. O seu backend tem que tratar isso de qualquer forma, mas saber o cronograma deles permite evitar promover um torneio em cima disso.

Diagnosticando de que lado está o problema​

SintomaLado
403 game_not_allowedSeu, ou da allowlist. Espere 30 s pelo cache antes
403 missing scope: ...Do host. A sua chave precisa desse escopo
403 tenant suspendedDo host. Questão de relacionamento
500 failed to mint viewer tokenDo host. A instância não tem chave de assinatura
ws_url aponta para a porta RESTDo host. A URL base pública de WS não está definida
WebSocket conecta e cai em ~60 sDo host. Idle timeout do load balancer
Gravações chegam mas parecem slideshowDo host. Gravadores sem aceleração de GPU
503 unavailable sob cargaCapacidade do host
Nenhum webhook chegandoSeu primeiro. Cheque se o endpoint é alcançável e se o segredo está definido
409 already in an active battleSeu. Uma batalha anterior não chegou a estado terminal

Cite as linhas do meio literalmente quando for reportar. 500 failed to mint viewer token em particular parece bug de aplicação e é chave faltando.

Perguntas que valem no primeiro dia​

  1. Quais são os valores das três janelas de lobby?
  2. Quais escopos a minha chave carrega?
  3. Quais ids de jogo estão liberados para o meu tenant?
  4. Existe chave de assinatura de viewer configurada? (Peça para emitirem um token e confirmarem.)
  5. Qual é o idle timeout do load balancer, comparado a uma batalha longa?
  6. Qual é o cronograma de atualização, e como somos avisados?
  7. Como as rotações de chave de assinatura são anunciadas?
  8. Qual é o teto de batalhas em voo, e quão perto dele a instância chega no pico?

As respostas mudam o que você constrói, então pergunte antes e não depois.

Próximo​