Experimentos · EXP-003
Renderização de áudio assíncrona numa plataforma sem estado
O projeto assíncrono do Soundcrafter falhou em produção: os trabalhos ficavam na fila em 0 %. A causa era a plataforma, não o código. A correção mudou o projeto e deixou um limite explícito.
O que esperávamos
O contrato permite provedores assíncronos: POST run responde 202 e o cliente consulta jobs/{requestId}. O Soundcrafter foi projetado assim porque uma renderização leva aproximadamente o mesmo tempo que o áudio que produz (uns 13 segundos para 14 segundos de música, num núcleo).
O que aconteceu
Implantados numa plataforma de funções sem estado, os trabalhos ficavam na fila em 0 % indefinidamente. A plataforma congela a função assim que envia a resposta, de modo que o trabalho em segundo plano nunca avançava. Além disso, uma dependência ausente matava a thread do trabalho sem deixar erro.
Correção
- Em plataformas sem estado, a renderização roda dentro da requisição e responde 200 com o resultado; o manifest anuncia
async: false. - Limite explícito de 20 segundos de áudio nesse modo; acima disso, a resposta é 413
too_large. - Uma dependência ausente é informada como
render_failed, com a causa. - Teste real com requisição HTTP: 13,1 s, resposta 200, WAV válido.
O que aprendemos
A suposição sobre onde o provedor rodaria não estava escrita em nenhum lugar compartilhado: vivia na cabeça de quem o projetou, e é o tipo de informação que o M1 tenta tornar visível. Mas a lição mais importante é sobre o F8: o problema só apareceu quando o sistema estava em uso, porque nada capturava sinais do ambiente real antes disso. A separação entre construir e implantar (M7) era, neste caso, o que impedia aprender a tempo.