El proxy de descarga del expediente comprobaba el status de EFC DENTRO del generador
de streaming. Starlette manda la linea de estado en cuanto construye la
StreamingResponse -antes de pedir el primer trozo-, asi que cuando el generador
descubria el 404 la respuesta ya habia salido con 200: el usuario recibia un archivo
vacio o cortado en vez del error. La traduccion asimetrica que fija el ticket
-404 pasa como 404, todo lo demas como 502- estaba escrita pero nunca llegaba a
ocurrir.
Ahora la conexion se abre y su status se valida ANTES de construir la respuesta, con
client.send(peticion, stream=True). El streaming se conserva intacto: lo unico que se
adelanta es la cabecera de EFC, que por protocolo llega antes que el cuerpo. El
cliente httpx se sigue creando fuera de todo `async with` y cerrandose en el finally,
que era la parte que si estaba bien.
De paso, un fallo de red contra EFC (timeout, conexion rechazada) daba un 500 opaco y
dejaba el cliente httpx sin cerrar; ahora sale 502 y se cierra. Es el mismo camino de
codigo que el ticket manda cubrir.
Se agregan las pruebas del proxy que el ticket exigia y que no existian: streaming
real -el cliente sigue vivo mientras se consumen los trozos y se cierra al terminar-,
la pertenencia validada antes de tocar EFC, el organizacion_id del expediente en la
peticion, que ninguna URL de almacenamiento se filtre al cuerpo ni a los headers, y
la traduccion completa de errores. Todo contra httpx.MockTransport, sin red.
stream_document y su ruta pasan a async por el cambio; la prueba del 409 en
test_expediente_upload gana su await, sin el cual la corrutina no se ejecutaba y la
prueba pasaba sin probar nada.
Refs: T2026-08-046 (fase 7)
marcos
d671558a59