Stream preparation progress instead of raising an error

#1
by multimodalart HF Staff - opened

The "initial conditions are being prepared" case is currently raised as a gr.Error, so a normal
in-progress state is shown to visitors as a red failure toast asking them to retry by hand.

This keeps the constraint the code documents -- never wait for the CPU prep inside the request that calls
the GPU function, because the ZeroGPU token attached to it expires after a couple of minutes -- and instead
splits the button into two events:

  • prepare_step: CPU only, no @spaces.GPU. Queues the preparation and streams progress until the tensor
    is cached (Fetching and preprocessing ... 45s elapsed), erroring only if PREP_TIMEOUT_S is reached.
  • forecast_step: chained with .success(), so it runs as its own request with a fresh ZeroGPU token.

One click, a progress message instead of an error, and the forecast starts by itself when the data lands.

forecast() is unchanged and still exposed as api_name="forecast" (via a hidden button, the same pattern
as gpu_ping), so the HTTP/MCP tool keeps its name, signature and docstring.

concurrency_limit=16 on the waiting step so several visitors polling at once don't queue behind each
other -- the actual work is already serialised by _prep_lock in the background thread.

multimodalart changed pull request status to merged

Sign up or log in to comment