Skip to content

Bug: Validate engine installation completion and preserve live install state #112

Description

@BerryUIKI

Summary

An existing empty ComfyUI directory, with mocked venv creation, was reported completed despite having no main.py. installer.py:161 skips cloning for any existing destination, and missing prerequisites can bypass dependency setup. Separately, installer.py:56 changes an in-progress manifest to interrupted whenever it is read, including ordinary live status polling.

Environment and evidence

  • Review finding: F12 (2026-10-05 product/technical review).
  • Baseline: Windows, dev at c1c5dbe. The remote dev matched this commit when filing.
  • Evidence: Reproduced.
  • Priority recommendation: P1 - proposed first-release blocker. This is review triage, not a production-incident severity declaration.
  • No real credentials, paid inference, engine installation, or unrelated process termination were used for review probes. Mocked observations establish the stated code behavior, not live-provider/GPU acceptance.

Reproduction or validation

Two isolated probes expose the installation-state contract. (1) Create an empty ComfyUI destination and mock venv creation as successful; install_engine reports completed with no main.py. (2) Write a DOWNLOADING manifest and read it through read_manifest; it becomes INTERRUPTED even though a live status read should not invalidate an active worker. No repository clone or package installation was performed.

User impact

Installed state is unreliable, retry can preserve broken directories, and the UI can misreport an installation while it is still running.

Proposed approach

Distinguish an active worker from a previous interrupted attempt, lock operations per engine, install into staging, and mark completion only after entrypoint, dependency, and smoke-health validation.

Acceptance criteria

  • Distinguish active installation workers from interrupted previous runs.
  • Status reads are side-effect-free for active installations.
  • Missing entrypoint, dependency setup, or validation prevents completed state.
  • Per-engine locking and staged promotion preserve existing working installations.
  • Interrupted and empty-directory retries recover without false success.

Verification scope

Real GPU inference, paid-provider compatibility, and a clean-machine packaged desktop journey remain unverified. Any follow-up implementation should target dev under the repository's contribution/branching rules.

Activity

  1. added
    bugSomething isn't working
    criticalCritical priority issues that block core functionality or cause vulnerabilities
    backendBackend Python / FastAPI / Engine issues
    on Oct 4, 2026
  2. added a commit that references this issue on Oct 4, 2026
    223a0ba
  3. BerryUIKI commented on Oct 4, 2026

    @BerryUIKI
    OwnerAuthor

    Resolved via PR #152.

    • Added in-memory tracking of active installation workers (_active_installs) in \IsolatedEngineInstaller\ so live status polling reads (
      ead_manifest) remain side-effect-free and do not prematurely mark in-progress installations as \INTERRUPTED.
    • Enforced exclusive async lease locks per engine type via \ ask_registry.get_install_lock.
    • Cleaned up empty or corrupt engine directories lacking valid entrypoints (\main.py, \launch.py/\webui.py) or .git\ before attempting clone.
    • Added strict post-installation verification (\�alidate_installation) ensuring entrypoint, hermetic Python binary, and
      equirements.txt\ are present before marking \COMPLETED.
    • Added unit tests in \ est_m2_engines.py\ covering live polling safety, corrupt/empty directory recovery, and lease locking.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    backendBackend Python / FastAPI / Engine issuesbugSomething isn't workingcriticalCritical priority issues that block core functionality or cause vulnerabilities

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions