Posso atualizar host e guest em momentos diferentes?
Posso atualizar host e guest em momentos diferentes?
Pergunta: "posso atualizar host e guest em momentos diferentes?"
Sim, com uma regra de ordem e uma proibição.
A regra de ordem
Sobe primeiro quem recebe o evento novo, depois quem envia:
- Evento novo host→guest: espere a adoção do app do guest (loja) antes de o host passar a enviá-lo.
- Evento novo guest→host: indolor — o host recebendo algo novo não quebra nada que já funcionava.
A proibição
Editar a forma de um evento já em uso é proibido. Faz-se nome novo. É a única disciplina que nunca aciona o caso fatal da tabela abaixo.
Tabela de compatibilidade
| situação | o que acontece |
|---|---|
| Mesmo nome, formatos concretos diferentes | FATAL — o guest encerra com ended{reason:'contract_mismatch'}; o host sobrevive, mesma sala, mesmo QR (ver maquina-de-estados.md). |
| Nome que só um lado conhece | Tolerado — a sala sobe na interseção; enviar esse nome específico lança usage (event_unknown_to_peer). |
protocolVersion diferente | FATAL, checado antes do fingerprint — mesma assimetria guest-termina/host-sobrevive. |
Forma opaca de um dos lados (Standard Schema / payload<T>()) | Compara-se só o nome — sem rede de proteção de formato naquele evento (ver seguranca.md). |
Servidor sem suporte a max_guests | A sala sobe normalmente; room.effectiveMaxGuests vem null (ver seguranca.md). |
O que consultar em runtime
O resultado do handshake é dado, não log: nomes só-meus, só-do-peer, comparados por forma, ou comparados só por nome. É assim que se descobre, em produção, que um evento perdeu a rede do fingerprint — não por inspeção manual.
Fronteira de versão
protocolVersion é um inteiro próprio da lib, desacoplado do semver do pacote npm — o pacote pode ir de 0.1.x a 3.7.x com protocolVersion continuando 1 o tempo todo; só sobe quando a semântica do envelope/handshake muda, nunca por causa de uma feature. A v1 já se auto-encerra diante de qualquer versão diferente (maior, menor, ausente ou malformada — todas contam como "diferente da minha", sem gradação) — é exatamente isso que torna uma v2 futura deployável sem coordenar as duas pontas no mesmo instante.
Notas de fato sobre o ciclo de vida do host
- Host sem sala aberta vive 30s —
pingnão estende esse prazo. Entre salas, o host tem um relógio correndo;startRoom()depois desse prazo reconecta de forma transparente. x-api-keyestá depreciada também do lado da plataforma — não é um caminho de versionamento válido para nada aqui.max_guests,room_fulle o eco deeffectiveMaxGuestsnoroom_createdestão confirmados para implementação do lado da plataforma — a marcação "requer servidor com suporte" em seguranca.md é uma janela, não um talvez indefinido.
O que permanece em aberto
Nada nesta página depende disso, mas para registro: o algoritmo exato do fingerprint (FNV-1a duplo, ver eventos.md) já está implementado e testado — não há mais buraco aqui.
Last updated on