Experiments · EXP-003
Asynchronous audio rendering on a stateless platform
Soundcrafter's asynchronous design failed in production: jobs stayed queued at 0%. The cause was the platform, not the code. The fix changed the design and left an explicit limit.
What we expected
The contract allows asynchronous providers: POST run answers 202 and the client polls jobs/{requestId}. Soundcrafter was designed that way because a render takes roughly as long as the audio it produces (about 13 seconds for 14 seconds of music, on one core).
What happened
Deployed on a stateless function platform, jobs stayed queued at 0% indefinitely. The platform freezes the function as soon as it sends the response, so background work never advanced. On top of that, a missing dependency killed the job thread without leaving an error.
Fix
- On stateless platforms the render runs inside the request and answers 200 with the result; the manifest advertises
async: false. - An explicit limit of 20 seconds of audio in that mode; beyond it, the answer is 413
too_large. - A missing dependency is reported as
render_failedwith its cause. - Real test with an HTTP request: 13.1 s, 200 response, valid WAV.
What we learned
The assumption about where the provider would run was not written anywhere shared: it lived in the head of whoever designed it, and that is the kind of information M1 tries to make visible. But the more important lesson concerns F8: the problem only appeared once the system was in use, because nothing captured signals from the real environment before that. The separation between building and deploying (M7) was, in this case, what prevented learning in time.