Experimentos · EXP-003
Render de audio asíncrono en una plataforma sin estado
El diseño asíncrono de Soundcrafter falló en producción: los trabajos quedaban en cola al 0 %. La causa era la plataforma, no el código. La corrección cambió el diseño y dejó un límite explícito.
Lo que esperábamos
El contrato permite proveedores asíncronos: POST run responde 202 y el cliente consulta jobs/{requestId}. Soundcrafter se diseñó así porque un render tarda aproximadamente lo mismo que el audio que produce (unos 13 segundos para 14 segundos de música, en un núcleo).
Lo que pasó
Desplegado en una plataforma de funciones sin estado, los trabajos quedaban en cola al 0 % indefinidamente. La plataforma congela la función en cuanto envía la respuesta, de modo que el trabajo en segundo plano nunca avanzaba. Además, una dependencia faltante mataba el hilo del trabajo sin dejar error.
Corrección
- En plataformas sin estado el render corre dentro de la petición y responde 200 con el resultado; el manifest anuncia
async: false. - Límite explícito de 20 segundos de audio en ese modo; más allá responde 413
too_large. - Una dependencia faltante se informa como
render_failedcon la causa. - Prueba real con petición HTTP: 13,1 s, respuesta 200, WAV válido.
Qué aprendimos
La suposición sobre dónde correría el proveedor no estaba escrita en ninguna parte compartida: vivía en la cabeza de quien lo diseñó, y es el tipo de información que M1 intenta hacer visible. Pero la lección más importante es sobre F8: el problema solo apareció cuando el sistema estuvo en uso, porque nada capturaba señales del entorno real antes. La separación entre construir y desplegar (M7) era, en este caso, la que impedía aprender a tiempo.