Expériences · EXP-003
Rendu audio asynchrone sur une plateforme sans état
La conception asynchrone de Soundcrafter a échoué en production : les tâches restaient en file à 0 %. La cause était la plateforme, pas le code. La correction a modifié la conception et laissé une limite explicite.
Ce que nous attendions
Le contrat autorise des fournisseurs asynchrones : POST run répond 202 et le client interroge jobs/{requestId}. Soundcrafter a été conçu ainsi parce qu’un rendu dure à peu près autant que l’audio qu’il produit (environ 13 secondes pour 14 secondes de musique, sur un cœur).
Ce qui s’est passé
Déployées sur une plateforme de fonctions sans état, les tâches restaient indéfiniment en file à 0 %. La plateforme gèle la fonction dès qu’elle envoie la réponse, de sorte que le travail en arrière-plan n’avançait jamais. De plus, une dépendance manquante tuait le fil d’exécution de la tâche sans laisser d’erreur.
Correction
- Sur les plateformes sans état, le rendu s’exécute dans la requête et répond 200 avec le résultat ; le manifest annonce
async: false. - Limite explicite de 20 secondes d’audio dans ce mode ; au-delà, la réponse est 413
too_large. - Une dépendance manquante est signalée comme
render_failed, avec sa cause. - Essai réel par requête HTTP : 13,1 s, réponse 200, WAV valide.
Ce que nous avons appris
L’hypothèse sur l’endroit où tournerait le fournisseur n’était écrite nulle part de façon partagée : elle était dans la tête de celui qui l’avait conçu, et c’est le type d’information que M1 cherche à rendre visible. Mais la leçon la plus importante concerne F8 : le problème n’est apparu qu’une fois le système en usage, parce que rien ne captait de signaux de l’environnement réel avant. La séparation entre construire et déployer (M7) était, ici, ce qui empêchait d’apprendre à temps.