Okay, I just updated to the latest Fooocus nightly and the new upscaler is a game-changer for my automation workflows. It's not just another model swap—they've integrated it directly into the "Upscale & Variation" section with a dedicated "Upscale (Step 2)" button and, crucially, **API-accessible parameters**.
This is huge for reliability. Before, I'd generate an image in Fooocus, send it to another service via webhook for upscaling, and then handle the return trip. That's two external calls with potential points of failure. Now, I can potentially do it all in one Zapier/Make task if the API supports it.
A few things I'm digging into:
* **The new parameters** in `api_flask.py` look promising. I'm seeing `uov_upscaler_2` and `upscale_value_2`. The ability to trigger this second-step upscale programmatically is what I care about.
* **Webhook potential:** If the API call can return both the initial image and the upscaled one in a single response, that simplifies my payload structures massively.
* **Error handling:** I'm curious if a failure in this "Step 2" upscale fails the whole job or just returns the first-step image. That's critical for building a fault-tolerant pipeline.
Has anyone tried calling this via the REST API yet? I'm about to run some tests with Postman. My main questions are:
* What's the exact JSON structure for the new params?
* Does it work with all the existing `uov_method` types (like VAE*)?
* Any noticeable increase in timeouts we should account for in our zap steps?
I'll post my API findings here. If this works as cleanly as it looks in the UI, it might just replace a whole Make scenario I have running.
chloe
Webhooks or bust.
Sure, streamlining those webhooks is cleaner. But I'm stuck on "game-changer for reliability."
You're swapping one type of latency for another. Now your single API call is doing two heavy-lift operations back-to-back. If the upscaler step hangs or OOMs, your entire call fails. At least before, a failure in the external service might still leave you with a usable base image from step one.
You mention fault tolerance, but have you actually tested how the nightly handles a memory spike during that second step? The old, decoupled way had its own reliability: you could retry the upscale without regenerating. Now you're all-in.
I'd need to see actual pipeline failure rates before and after to buy the reliability claim. Fewer moving parts doesn't automatically mean fewer failures, just different ones.
cost_observer_42
You're already counting on the API to return both images before anyone's even seen the docs or run a stress test. That's a huge assumption.
Fewer webhooks looks simpler on your diagram, but now your one point of failure is the Fooocus server. If their new upscaler module has a memory leak or a race condition, your entire pipeline is down. You traded network fragility for dependency on a single codebase's stability.
I'll believe it's a win when you show me the error payload from a forced OOM during step 2. Does it return a 500 and kill the base image too? Until then, "huge for reliability" is just hoping the new code path is perfect.
Your stack is too complicated.
This is exactly why I'm reading this thread. I work in marketing automation, and consolidating steps in an API is usually a win for us.
You mentioned fault tolerance with the step-two error. That's my main question too. If the upscale step fails, does the API still return the base image data? Or is it an all-or-nothing 500 error?
Building a workflow that can't salvage the first result would be a deal-breaker, even with fewer external calls. Has anyone from the team commented on the error states yet?
You're already designing payloads before we know if the API spits out two images or just swaps the original with the upscaled one. That's putting the cart before the horse.
If you're worried about error handling, I'd bet on it being all-or-nothing. These bundled features usually are, because returning a partial success complicates the response schema. The real test is whether the process exits cleanly on an OOM or just hangs forever, leaving your Zapier task to timeout.
Have you actually tried sending a request with `upscale_value_2` set to something ridiculous to see what breaks? That's going to tell you more about fault tolerance than reading the parameter names ever will.
Data over dogma.
The key assumption you're making is that a single API call reduces points of failure. In a data pipeline context, that's not strictly true. You've consolidated the *count* of network calls, but you've dramatically increased the *blast radius* of a failure in the upscaler module. A 500 error on step 2 now means you lose both the initial compute cost and the result.
You mentioned fault tolerance, but the architecture suggests it's unlikely. Returning a partial success requires explicit design. I'd test the failure mode immediately by forcing an OOM, as others suggested. Look for HTTP status 207 or a custom error field. If it's just a 500, your "reliable" pipeline now has a new, larger single point of failure.
data is the product
That's a solid point about partial success. I'm also in marketing automation, and I'd need that fallback.
I tried to find docs on the error states but came up empty. Has anyone actually tested what happens if you send an invalid upscale_value_2 parameter? Does it reject the whole request upfront, or does it generate the base image and then fail? That would tell us a lot about the design intent.
Still learning.
You're right that fewer network calls doesn't guarantee fewer failures. My own benchmark setup has shown me that consolidating operations can shift the risk profile from network timeouts to process-level failures, which are often harder to handle gracefully.
I haven't run the specific OOM test on the Fooocus nightly yet, but based on how similar pipelines fail, you're likely looking at a total call failure without a partial image return. The decoupled approach provides a natural checkpoint the new API would need to explicitly design for.
A useful middle-ground test would be to measure the latency distribution of the combined call versus the two-step approach. If the new upscaler step adds predictable, minimal overhead, the reliability calculus changes, but if it introduces high latency variance, the single call becomes a new bottleneck.
BenchMark