Ticketing Regras de Correspondência de Resposta (Implementação do Cliente)
Como as respostas podem chegar fora de ordem em relação às requisições (a resposta de uma aquisição que esperou chega quando sua vez chega), o cliente deve parear as respostas com as requisições usando as seguintes regras — um esquema de demultiplexação que separa as respostas intercaladas em uma conexão de volta para suas requisições.
| Regra | Detalhe |
|---|---|
| Chave de correspondência | Rejeição definitiva por capacidade de fila/servidor; retornar Busy imediatamente, sem retry interno |
| Múltiplas requisições com o mesmo (op, key) | Não presuma FIFO — identifique sempre pelo identificador. Veja a explicação abaixo |
| Momento de registro | Quem espera é registrado antes de a requisição ser enviada (para evitar uma corrida em que a resposta chega primeiro) |
Tratamento de N/T | Retornados como valores que não são erro ("não existia" / "tempo esgotado") |
Tratamento de B | Fila cheia — não falhe de imediato; tente novamente com backoff dentro do orçamento de wait |
Tratamento de M | Guardar só endereço allowlisted como leader hint e fechar; sem owner/key não há correlação com pending enviados |
Tratamento de L | Atualizar só leader hint e manter conexão; aviso do servidor, não resposta |
E no_leader / E not_active / E auth_failed | Fechar e aplicar backoff por erro; no_leader também invalida o hint |
Outro E / resposta desconhecida | Não correlacionável, portanto connection-fatal; acquires enviados ficam Indeterminate |
| Resposta sem quem espere correspondente | Incompatibilidade protocol/session: fechar. Para A, passar exact token conhecido à reserved release lane |
Por que correlacionar pelo identificador, e não por FIFO
Mesmo para uma key, sucesso imediato, espera na fila e rejeição B terminam em momentos diferentes. Várias keys também usam pipeline numa conexão. Nunca associe por FIFO; verifique identifier ecoado, op e key juntos.
Requisições abortadas e locks órfãos
Se uma requisição cancelada já recebeu grant no servidor, o lock pode permanecer. Após enviar um byte sem resposta definitiva, o resultado é Indeterminate. Não reenvie A com o mesmo owner como consulta de estado. Só se o token já foi parseado, envie best-effort exact-token R; grant desconhecido é recuperado por lease expiry.
Por isso a conexão fecha após cancelamento pós-envio ou erro de framing. Descartar só pending pode deixar resposta órfã. Socket close não prova release de grant committed: exact-token R se conhecido; senão, Indeterminate até lease expiry.