Prove what changed before you roll Forge back

Reproduce one unchanged job on a clean checkout of the current commit and a separate clean checkout of the last known-good commit. If current fails repeatedly while known-good passes and the environment, artifacts and settings match, you have credible evidence of an update regression.

Stop changing files. Save the complete console log, current commit, Git status, System info, launch arguments and failing output. Then test a separate clean current install with extra extensions disabled.

A Git checkout can use git rev-parse HEAD. Forge also prints a commit hash during launch. Use the complete hash in your notes rather than “latest.”

Last-good is the newest exact commit where your controlled job passes. First-bad is the earliest exact commit where the same job fails. A large gap identifies a boundary but not the individual change.

Yes for a credible core claim. A separate clean current checkout removes accumulated source edits, extension code and environment history from the first comparison.

It is possible, but it is weaker evidence because the venv, generated files and settings may remain changed. A separate checkout with its own environment is safer and easier to compare.

No. Git changes tracked source files; it does not reconstruct the exact previously installed Python environment. That is why each comparison checkout should have its own environment.

Not first. Preserve evidence and identify the failure boundary. If you need a clean environment, create it in a separate checkout or rename the verified Forge-local venv so the previous state remains recoverable.

Start current Forge with --disable-extra-extensions. If core generation passes, enable only the affected extension and record its remote and commit. Test cross-extension pairs only when each extension passes alone.

That result implicates an extra extension or extension interaction, not core Forge. Continue with the extension and Gradio diagnostic instead of rolling back the core immediately.

Built-in extensions still load with that flag. For a deeper diagnostic, --disable-all-extensions prevents all extensions from loading. Record which flag produced each result.

Do not assume the source changed first. Match the diffusion model and hash, quantization, VAE, CLIP-L, T5, preset, memory controls and extension state. Then compare clean current and known-good commits.

No as a generic FLUX rollback. The official previous F0.0.17 archive was published in July 2024 before original Forge added FLUX support. Use a commit you personally verified with your FLUX workflow.

Prompt alone is not a fixed job. Match the exact artifact hashes, seed, size, sampler, scheduler, steps, CFG, VAE/text encoders, preset, extensions and relevant Forge controls.

Use the dedicated benchmark protocol: same hardware and artifacts, matched settings, separate cold and warm observations, multiple retained runs, and full logs for both named commits.

No. First-run loading, caching, temperature and background work can distort one observation. Repeat a controlled warm series and retain all results.

The full System info implementation records Forge version and commit, Git status, command line, Torch environment, hardware, settings, packages, enabled and inactive extra-extension revisions, and startup information. Review it before sharing.

No. At the inspected commit, the command-line help explicitly describes --dump-sysinfo as limited and without extension or option information. Use it for a startup failure, but add the missing state manually.

Review local paths, usernames, tokens, authentication values, private remotes, prompts and public share URLs. Forge hides matching Gradio/API auth arguments in System info, but you still need to inspect the file and logs.

Use the original lllyasviel/stable-diffusion-webui-forge issue tracker after searching for an existing report. Do not report a fork-specific failure as an original Forge bug.

Yes, if you first preserve the failing commit, logs, System info and minimal job. Restore a known-good state in another folder so recovery does not erase the evidence.

The exact boundary is UNKNOWN. Inspect logs, old System info, folder copies or launch screenshots for a hash. If none exists, establish a new baseline instead of guessing an old version.

Label it intermittent, record every pass and failure, and look for uncontrolled differences such as memory pressure, extension order, shared state or warm/cold conditions. Do not present it as deterministic.

One original-repository issue, one smallest repeatable job, current-fails / known-good-passes evidence, both complete commits and logs, reviewed System info, exact artifacts, extension state, and clear expected versus actual behavior.