# Plano de Testes — TIA Regional / Pool xAI

## Objetivo

Validar separadamente capacidade do pool, comportamento do Kubernetes, failover regional, impacto de latência e resiliência do xAI.

## Camada 1 — Smoke

1. subir 1 Pod ORD com pool pequeno (`XAI_POOL_SIZE=3`);
2. confirmar 3 conexões healthy;
3. realizar uma chamada e uma síntese;
4. confirmar que `leased` vai 0 -> 1 -> 0;
5. confirmar que o socket upstream continua healthy após `audio.done`.

## Camada 2 — Prewarm

Subir com um `XAI_POOL_SIZE` representativo da configuração alvo (50 abaixo é apenas exemplo) e medir:

- tempo total até Ready;
- taxa de sucesso de handshake;
- número máximo de handshakes simultâneos;
- impacto de `XAI_POOL_PREWARM_CONCURRENCY` 2, 5 e 10.

Critério inicial: nenhuma rajada deve reproduzir os erros de conexão observados no modelo burst.

## Camada 3 — Saturação

Gerar mais utterances concorrentes que slots.

Esperado:

- leases nunca superam `XAI_POOL_SIZE`;
- acquire espera até `XAI_POOL_ACQUIRE_TIMEOUT_S`;
- readiness fica 503 quando free cruza threshold;
- novas chamadas deixam de entrar naquele Pod;
- chamadas existentes continuam.

## Camada 4 — Histerese

Com size=10:

```text
UNAVAILABLE_FREE=2
RECOVER_FREE=5
```

Esperado:

- free=2 -> NotReady;
- free=3/4 -> continua NotReady;
- free=5 -> Ready.

## Camada 5 — Refresh

Use TTL curto em FQA:

```text
XAI_POOL_CONNECTION_TTL_S=60
XAI_POOL_REFRESH_JITTER_S=20
```

Observe por 5 minutos.

Esperado:

- sockets são renovados individualmente;
- não existe burst de reconnects equivalente ao tamanho total do pool;
- slots ocupados não são renovados no meio da síntese;
- pool retorna ao tamanho configurado.


## Camada 6 — Barge-in / clean boundary

Com uma síntese longa em andamento:

1. aguardar pelo menos um `audio.delta`;
2. simular interrupção do usuário;
3. confirmar envio de `text.clear` ao sidecar;
4. fazer o fake/provider enviar 1 ou mais `audio.delta` residuais antes de `audio.clear`;
5. confirmar que os frames residuais **não** chegam ao LiveKit;
6. confirmar `audio.clear` entregue ao TIA;
7. confirmar `leased` retorna ao valor anterior sem fechar o socket;
8. iniciar nova utterance e validar ausência de áudio da utterance cancelada.

Critérios:

- `tia_xai_pool_barge_ins_total` incrementa;
- `tia_xai_pool_barge_in_reuses_total` incrementa quando `audio.clear` é confirmado;
- `tia_xai_pool_barge_in_discarded_messages_total` contabiliza frames residuais;
- se `audio.clear` não chegar dentro de `XAI_POOL_BARGE_IN_CLEAR_TIMEOUT_S`, `tia_xai_pool_barge_in_resets_total` incrementa e o slot é recriado.

## Camada 7 — Falha upstream

Bloqueie ORD ou aponte temporariamente para endpoint inválido.

Esperado:

- slots ORD tornam-se unhealthy;
- maintenance tenta recuperação;
- readiness ORD cai;
- Service deixa de enviar novas chamadas a ORD;
- IAD continua Ready.

## Camada 8 — Latência

Compare três cenários:

A. TIA -> xAI direto sem pool

B. TIA -> localhost pool -> xAI com socket já aquecido

C. TIA -> localhost pool -> xAI durante recuperação/abertura de socket

Meça:

- `provider_ttfb_ms`;
- `end_to_end_ttfb_ms`;
- `max_audio_delta_gap_ms`;
- `xai_underrun_estimado_ms`;
- connect time do upstream;
- `pool_free` e `pool_leased`.

Hipótese: o hop localhost adiciona latência desprezível frente ao TTFB do provider, enquanto remove handshake xAI do caminho crítico na situação normal.

## Camada 9 — Carga semelhante a produção

Evite somente burst C=200. Use sockets persistentes e concorrência de síntese representativa da operação real, seguindo a metodologia que produziu resultados reprodutíveis nos testes anteriores.

Rodar pelo menos:

```text
20% da carga alvo
50%
80%
100%
120% por janela curta
```

## Camada 10 — Rollout

Com chamadas ativas:

```bash
kubectl rollout restart deployment/<tia-ord>
```

Validar:

- Pod antigo entra em drain;
- não recebe novas conexões;
- Pod novo preaquece antes de ficar Ready;
- `maxUnavailable=0` preserva capacidade durante rollout.

## Camada 10 — Failover regional

1. ORD e IAD Ready;
2. iniciar tráfego contínuo;
3. tornar ORD NotReady;
4. verificar novas chamadas em IAD;
5. recuperar ORD;
6. verificar reentrada progressiva.

## Evidências a guardar

- logs do sidecar;
- `/pool/status` em intervalos de 1s;
- métricas Prometheus;
- logs TIA de TTFB/underflow;
- quantidade de endpoints Ready por região;
- distribuição de chamadas por Pod;
- erros de WebSocket upstream;
- timestamps de `audio.done`.
