Ticketing Reglas de emparejamiento de respuestas (implementación del cliente)
Como las respuestas pueden llegar en un orden distinto al de las solicitudes (la respuesta a una adquisición que estuvo esperando llega cuando le toca su turno), el cliente debe emparejar las respuestas con las solicitudes según las siguientes reglas — un esquema de desmultiplexado que reparte las respuestas entremezcladas en una conexión de vuelta a sus solicitudes.
| Regla | Detalle |
|---|---|
| Clave de emparejamiento | Rechazo definitivo por capacidad de cola/servidor; devolver Busy de inmediato, sin retry interno |
| Varias solicitudes con el mismo (op, clave) | No des por supuesto FIFO — identifica siempre por el identificador. Consulta la explicación de abajo |
| Momento de registro | El esperador se registra antes de enviar la solicitud (para evitar una carrera en la que la respuesta llegue primero) |
Manejo de N/T | Se devuelven como valores que no son error ("no existía" / "tiempo agotado") |
Manejo de B | Cola saturada — no falles de inmediato; reintenta con backoff dentro del presupuesto de wait |
Manejo de M | Guardar solo una dirección allowlisted como leader hint y cerrar; sin owner/key no puede correlacionarse con pending enviados |
Manejo de L | Actualizar solo leader hint y mantener conexión; aviso del servidor, no respuesta |
E no_leader / E not_active / E auth_failed | Cerrar y aplicar backoff según error; no_leader invalida también el hint |
Otro E / respuesta desconocida | No correlacionable, por tanto connection-fatal; acquires enviados quedan Indeterminate |
| Respuesta sin esperador que la reclame | Desajuste protocol/session: cerrar. Para A, pasar exact token conocido a reserved release lane |
Por qué emparejar por identificador y no por FIFO
Incluso para una key, el éxito inmediato, la espera en cola y el rechazo B terminan en momentos distintos. Varias keys también se canalizan por una conexión. Nunca empareje por FIFO; verifique juntos identifier repetido, op y key.
Solicitudes abortadas y bloqueos huérfanos
Si una solicitud cancelada ya recibió grant en el servidor, el bloqueo puede quedar. Tras enviar un byte sin respuesta definitiva, el resultado es Indeterminate. No reenvíe A con el mismo owner como consulta de estado. Solo si ya se parseó el token, envíe best-effort exact-token R; un grant desconocido lo recupera lease expiry.
Por eso se cierra tras cancelación posterior al envío o error de framing. Descartar solo pending puede dejar huérfana una respuesta. Socket close no prueba release de un grant committed: exact-token R si se conoce; si no, Indeterminate hasta lease expiry.