# 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 [#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 [#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 [#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](/pt/docs/event-room/latest/markdown/maquina-de-estados)). |
| 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](/pt/docs/event-room/latest/markdown/seguranca)).                                                         |
| Servidor sem suporte a `max_guests`                            | A sala **sobe** normalmente; `room.effectiveMaxGuests` vem `null` (ver [seguranca.md](/pt/docs/event-room/latest/markdown/seguranca)).                                                                 |

## O que consultar em runtime [#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 [#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 [#notas-de-fato-sobre-o-ciclo-de-vida-do-host]

* Host sem sala aberta vive **30s** — `ping` não estende esse prazo. Entre salas, o host tem um relógio correndo; `startRoom()` depois desse prazo reconecta de forma transparente.
* `x-api-key` está depreciada também do lado da plataforma — não é um caminho de versionamento válido para nada aqui.
* `max_guests`, `room_full` e o eco de `effectiveMaxGuests` no `room_created` estão **confirmados para implementação** do lado da plataforma — a marcação "requer servidor com suporte" em [seguranca.md](/pt/docs/event-room/latest/markdown/seguranca) é uma janela, não um talvez indefinido.

## O que permanece em aberto [#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](/pt/docs/event-room/latest/markdown/eventos)) já está implementado e testado — não há mais buraco aqui.