ajuste no contas
This commit is contained in:
19
docs/FIX_TEST24_AOFERTA_HTTPX_LIFECYCLE_20260901.md
Normal file
19
docs/FIX_TEST24_AOFERTA_HTTPX_LIFECYCLE_20260901.md
Normal file
@@ -0,0 +1,19 @@
|
||||
# Teste 24 — contexto AOFERTA e lifecycle do cliente HTTP
|
||||
|
||||
## Problemas corrigidos
|
||||
|
||||
1. A resposta terminal de cancelamento parcial era corretamente produzida pelo workflow, porém o TIM_AOFERTA podia receber um contexto JSON enorme truncado antes das evidências relevantes do pedido. Isso fazia a orientação de canal alternativo para o mesmo alvo ser julgada como ação não solicitada.
|
||||
2. O bridge síncrono de guardrails executava um provider temporário dentro de `asyncio.run()`. O `AsyncOpenAI`/httpx associado podia sobreviver ao loop e tentar fechar conexões após o loop ter sido encerrado, gerando `Task exception was never retrieved` / `RuntimeError: Event loop is closed`.
|
||||
|
||||
## Correções
|
||||
|
||||
- `TimProactiveOfferRail` usa contexto compacto e autoritativo com histórico recente, pedido/resolução transacional e resultado atual da execução. Não existe bypass para estado `COMPLETED`: o LLM continua julgando semanticamente e ainda pode bloquear alvo/ação realmente novos.
|
||||
- O prompt AOFERTA explicita que evidência estruturada do alvo solicitado/resolvido e da falha parcial é autoritativa para continuidade no mesmo alvo.
|
||||
- Providers OpenAI-compatible ganharam `aclose()` explícito para todos os clientes cacheados.
|
||||
- `classify_with_framework_llm()` identifica providers temporários criados internamente e os fecha no mesmo event loop, em `finally`; providers fornecidos pelo caller continuam sob responsabilidade do caller.
|
||||
|
||||
## Testes
|
||||
|
||||
- lifecycle + TIM_AOFERTA: 22 PASS
|
||||
- cancelamento/guardrails correlatos: 198 PASS
|
||||
- `tests/migration`: 830 PASS / 2 FAIL históricos não relacionados.
|
||||
Reference in New Issue
Block a user