Skip to content

(fix): clear stale install data before starting new installation#11716

Merged
abnegate merged 1 commit into1.9.xfrom
fix-installer
Mar 31, 2026
Merged

(fix): clear stale install data before starting new installation#11716
abnegate merged 1 commit into1.9.xfrom
fix-installer

Conversation

@abnegate
Copy link
Copy Markdown
Member

What does this PR do?

(Provide a description of what this PR does and why it's needed.)

Test Plan

(Write your test plan here. If you changed any code, please provide us with clear instructions on how you verified your changes work. Screenshots may also be helpful.)

Related PRs and Issues

  • (Related PR or issue)

Checklist

  • Have you read the Contributing Guidelines on issues?
  • If the PR includes a change to an API's metadata (desc, label, params, etc.), does it also include updated API specs and example docs?

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai bot commented Mar 31, 2026

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: f924a750-24b0-4852-a60a-49782baf660e

📥 Commits

Reviewing files that changed from the base of the PR and between 416b26a and f9aee4d.

📒 Files selected for processing (2)
  • app/views/install/installer/js/installer.js
  • app/views/install/installer/js/modules/progress.js

📝 Walkthrough

Walkthrough

The changes refactor the installer's step advancement and installation state management. The click handler for step 5 now executes optional validation followed by unconditional clearing of stale install state, replacing the previous gated approach. The progress module updates its terminal state detection to return specific state strings ('empty', 'error', 'completed', or false) instead of boolean values, and adjusts the resume logic to handle completion states separately from other terminal states. The startup flow now triggers an SSL check redirect for completed installs instead of attempting recovery.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix-installer

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

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

@abnegate abnegate merged commit c444bcc into 1.9.x Mar 31, 2026
10 of 11 checks passed
@abnegate abnegate deleted the fix-installer branch March 31, 2026 10:09
@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps bot commented Mar 31, 2026

Greptile Summary

This PR fixes two related bugs in the Appwrite installer UI: (1) stale install data causing the installer to resume a failed/old installation instead of starting fresh when the user navigates back and retries, and (2) a wrong redirect to step 1 when the installer page is reloaded after a successful installation (should redirect to the console instead).

Confidence Score: 5/5

Safe to merge; only finding is a P2 style observation about a silent no-op that is likely intentional.

All logic paths were traced end-to-end: install-lock/ID clearing in installer.js happens before loadStep so initStep5 always sees clean state; the isSnapshotTerminal contract change has a single caller that was fully updated; the 'completed' redirect path correctly skips recoverToLastStep(); and notifyInstallComplete handles undefined gracefully so the redirect is never blocked.

No files require special attention beyond the P2 observation in progress.js around clearInstallId being called before startSslCheck.

Important Files Changed

Filename Overview
app/views/install/installer/js/installer.js Clears stale install lock and ID before navigating to step 5 via the next button, ensuring initStep5 starts a fresh installation instead of attempting to resume a previous one. Logic is correct — clearing happens after validation and before loadStep, with no race conditions.
app/views/install/installer/js/modules/progress.js Three coordinated changes: isSnapshotTerminal now returns a discriminated string/false value; resumeInstall properly returns 'completed' for already-finished installs; initStep5 handles the 'completed' result by redirecting to the app. Minor: clearInstallId is called before startSslCheck(null), making getStoredInstallId unavailable in showRedirectStep and causing notifyInstallComplete to silently no-op — likely intentional but undocumented.

Reviews (1): Last reviewed commit: "(fix): clear stale install data before s..." | Re-trigger Greptile

Comment on lines +1098 to +1105
if (result === 'completed') {
// Install already finished — redirect to console
// instead of bouncing back to step 1.
stopSyncedSpinnerRotation();
setUnloadGuard(false);
clearInstallLock?.();
clearInstallId?.();
startSslCheck(null);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 notifyInstallComplete silently no-ops in the completed-reload path

clearInstallId?.() is called on line 1104 before startSslCheck(null) on line 1105. By the time showRedirectStep runs and evaluates activeInstall?.installId || getStoredInstallId?.(), both sources are nullactiveInstall was never set in this branch and the stored ID was just cleared. As a result, notifyInstallComplete is called with undefined and short-circuits immediately (if (!installId) return Promise.resolve()).

The redirect still happens correctly via .finally(), and since this path represents a reload of an already-completed install (no new session data to report), skipping the notification is arguably intentional. However, the getStoredInstallId?.() fallback added to showRedirectStep provides no benefit in this code path. A brief comment explaining the intentional skip would help future readers.

@github-actions
Copy link
Copy Markdown

github-actions bot commented Mar 31, 2026

🔄 PHP-Retry Summary

Flaky tests detected across commits:

Commit f9aee4d - 2 flaky tests
Test Retries Total Time Details
UsageTest::testVectorsDBStats 1 10.15s Logs
TablesDBConsoleClientTest::testEnforceCollectionPermissions 1 194ms Logs

@github-actions
Copy link
Copy Markdown

✨ Benchmark results

  • Requests per second: 1,666
  • Requests with 200 status code: 299,996
  • P99 latency: 0.106447435

⚡ Benchmark Comparison

Metric This PR Latest version
RPS 1,666 1,198
200 299,996 215,685
P99 0.106447435 0.185732105

@blacksmith-sh

This comment has been minimized.

@blacksmith-sh
Copy link
Copy Markdown

blacksmith-sh bot commented Mar 31, 2026

Found 1 test failure on Blacksmith runners:

Failure

Test View Logs
› Tests\E2E\Services\Databases\LegacyCustomClientTest/testUniqueIndexDuplicate View Logs

Fix in Cursor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant