Auto-update requirements after maintenance fixes

[benceruleanlu]

Summary

• keep Reset virtual environment focused on recreating the venv + pip upgrade
• after any maintenance fix, re‑validate and auto‑update requirements when mismatches are detected
• keep auto‑update as the default for any requirements mismatch (no allow‑list gating)
• update tests to reflect the maintenance flow

Why

Resetting the venv should not silently bundle a full requirements install. Instead, we now re‑run validation after maintenance actions and, if requirements are out of date, trigger the standard auto‑update path. This preserves the default auto‑update behavior for new dependencies while keeping the maintenance UX consistent.

UX Behavior

• Broken venv still opens Maintenance.
• Clicking Reset virtual environment recreates the venv and upgrades pip.
• After the reset, validation detects missing packages and auto‑updates them (desktop‑update screen).
• The “Install python packages” card remains available for manual reinstall if auto‑update fails.

Testing

• yarn format
• yarn lint
• yarn typecheck
• yarn test:unit

Notes

• Playwright E2E not run locally (CI will cover)

Summary by CodeRabbit

• Bug Fixes

  • Virtual environment troubleshooting more reliably treats out-of-date requirements as requiring a package upgrade.
  • Installation flow now re-validates after user fixes and triggers package updates when needed.

• Refactor

  • Simplified package requirement checking and logging for clearer outcomes.
  • Streamlined virtual environment reset messaging and workflow.

• Tests

  • Updated unit and integration tests to match the simplified requirement checks and troubleshooting flow.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

📝 Walkthrough

Walkthrough

hasRequirements now classifies any missing or out-of-date core/manager package as package-upgrade with consolidated logging; unit and integration tests updated for the simplified messages and flows; installationManager.resolveIssues always re-validates via installation.validate() and triggers updatePackages when needsRequirementsUpdate; troubleshooting comment wording adjusted.

Changes

Cohort / File(s)	Summary
Virtual Environment Requirements src/virtualEnvironment.ts	Reworked hasRequirements: removed helper upgrade-detection logic and multi-branch outcomes; any missing/out-of-date core or manager package is reported as 'package-upgrade'; log output consolidated.
Unit Tests tests/unit/virtualEnvironment.test.ts	Expectations simplified to a single unified log message and unified flag assertions; return values for affected cases remain 'package-upgrade'.
Installation Manager src/install/installationManager.ts	resolveIssues:onInstallFix now always calls installation.validate() and, if needsRequirementsUpdate is set, calls updatePackages() afterwards (removed the prior conditional/commented check).
Reset Venv / Troubleshooting src/install/troubleshooting.ts	Minor comment change in UV_RESET_VENV handler (textual wording update only).
Integration Test (post-install) tests/integration/post-install/troubleshootingVenv.spec.ts	Removed the installPythonPackagesCard flow from "Can fix venv" test; test now proceeds only with resetVenvCard workflow after venv recreation.

Sequence Diagram(s)

(Skipped — changes are multiple but do not introduce a new multi-component sequential feature that warrants a diagram.)

Possibly related PRs

• Update NVIDIA torch version on updates #1513: Overlaps with src/virtualEnvironment.ts changes — both touch upgrade-detection/requirements logic (NVIDIA/PyTorch-specific logic in that PR vs. simplification here).
• Prepare manager pip support #1450: Also modifies src/virtualEnvironment.ts and manager/core requirement handling; closely related to the requirements classification changes.

Poem

🐰 I hopped through packages, tidy and light,
One message now guides me through day and night.
Validate, then patch — a single gentle drum,
Tests nod, logs whisper, then I hop home, hum.

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The PR title 'Auto-update requirements after maintenance fixes' is closely aligned with the core objective of automatically installing Python requirements after venv reset maintenance actions.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/venv-troubleshooting-upgrade

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Copilot]

Pull request overview

This PR changes the error handling behavior for virtual environment requirements validation. When requirements are missing or incomplete and don't match known upgrade patterns, the code now returns 'error' instead of 'package-upgrade'.

Changes:

• Modified return value from 'package-upgrade' to 'error' for non-OK requirements that don't match known upgrade patterns
• Updated log message and level (info → warn) to reflect the new error classification

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

This change modifies the behavior in comfyInstallation.ts where 'package-upgrade' is treated as OK with a warning (lines 168-170). After this change, cases that previously returned 'package-upgrade' will now return 'error', which will be treated as a genuine error (lines 172-173) instead of OK with a warning.

This is a breaking behavioral change that affects the validation flow. Previously, unknown missing packages were tolerated as a warning; now they will be treated as errors. Consider whether this is the intended behavior and ensure it's properly documented and that any downstream consumers are updated accordingly.

[Copilot]

The log message "Requirements are missing or out of date. Treating as error." is potentially misleading. This code path is reached when requirements are NOT OK AND do not match known upgrade patterns. It's not necessarily about being "out of date" - it could be truly missing packages or unexpected package changes.

Consider clarifying the log message to be more precise, such as "Requirements check failed with unknown or unexpected package changes. Treating as error." This would better distinguish it from the known upgrade cases that are handled at lines 966-968.

Suggested change

	log.warn('Requirements are missing or out of date. Treating as error.', {
	log.warn('Requirements check failed with unknown or unexpected package changes. Treating as error.', {

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 024652d33f

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[coderabbitai]

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

src/virtualEnvironment.ts (1)

883-889: ⚠️ Potential issue | 🟠 Major

Update JSDoc and fix call site logic to distinguish 'package-upgrade' from 'error'.

The JSDoc still references the outdated 'manager-upgrade' value instead of the current 'package-upgrade' return type. Additionally, the call site at line 324 incorrectly treats 'package-upgrade' (known safe upgrades) the same as 'error' (unexpected missing packages) by calling manualInstall() for both. Only 'error' should trigger a manual install; 'package-upgrade' should allow the application to proceed (similar to the comfyInstallation.ts:167 call site behavior).

Update the JSDoc to accurately reflect the three return values and their semantics, and fix the logic at line 326 to handle 'package-upgrade' and 'error' separately:

Suggested changes

1. Lines 887-889 — Update JSDoc:

-   * `@returns` `'OK'` if pip install does not detect any missing packages,
-   * `'manager-upgrade'` if `uv` and `toml` are missing,
-   * or `'error'` when any other combination of packages are missing.
+   * `@returns` `'OK'` if all required packages are installed and up to date,
+   * `'package-upgrade'` if missing packages match a known safe upgrade pattern,
+   * or `'error'` for any other missing or unexpected package combination.

2. Lines 326-331 — Handle 'package-upgrade' separately from 'error':

         if (requirementsStatus === 'OK') {
           log.info('Skipping requirements installation - all requirements already installed');
+        } else if (requirementsStatus === 'package-upgrade') {
+          log.info('Known package upgrade detected - proceeding with installation');
-        } else {
+        } else if (requirementsStatus === 'error') {
           log.info('Starting manual install - venv missing requirements');
           await this.manualInstall(callbacks);
         }

[benceruleanlu]

Addressed review feedback: removed allow‑list gating to preserve auto‑update for any mismatch, reset now installs requirements, tests updated, docs/logs aligned.