Skip to content

Schema updater: repair and retry once when a step names a missing table - #2001

Merged
mastacontrola merged 1 commit into
FOGProject:working-1.6from
cepadugato:fix/schema-retry-after-missing-table
Oct 28, 2026
Merged

mastacontrola merged 1 commit into
FOGProject:working-1.6from
cepadugato:fix/schema-retry-after-missing-table

Conversation

@cepadugato

Copy link
Copy Markdown

Problem

Upgrading a fresh 1.5.10.2518 to RC-19 stops on the first pass:

 * Updating Database...........................................Failed!
Update ID: 290
... 1146 Table 'fog.fileDeleteQueue' doesn't exist ...
SQL: ALTER TABLE `fileDeleteQueue` ADD `fdqPathType` VARCHAR(255) NOT NULL

A second installfog.sh run finishes the upgrade. Details in #2000.

Cause

1.5.10.2518 arrives at vValue 288. 1.6 fills positions 287 and 288 with CREATE TABLE fileDeleteQueue and its first ALTERs, so the updater skips them, and // 290 ALTERs a table that is not there. 1146 is not in $skiperrs, so update() breaks out of the loop. The reconcile after the loop then creates the table, two seconds later in the lab. But the error is already recorded, so the installer prints Failed! and vValue stays at 289.

The second run works because it starts from the database that reconcile already repaired.

Fix

_repairAndRetry(): on 1146, run SchemaReconciler::reconcile() at the point of failure, then execute the same statement once more. The statement then succeeds, or hits a code $skiperrs already tolerates (1060 here, since the reconciler creates the table in its final shape). That is the second run's path, taken inside the first.

Unchanged:

  • any error other than 1146;
  • a repair that does not return true, which leaves the statement's own error for the caller to report;
  • a retry that still fails, which is not retried again.

A server whose tables all exist never sees 1146, so nothing changes for it. $skiperrs and SchemaReconciler::$_skiperrs are not touched, so tests/schema-executes.test.php's check that the two lists match is not affected.

Tests

  • New tests/schema-updater-repairs-missing-table.test.php, 16 checks, no database. It covers the repair and retry, a retry that lands on 1060, a retry that fails again, a repair that fails, three other error codes, and the call site in update(). It fails with the method removed, and fails 1 of 16 with only the call site removed.
  • tests/run-all.sh: 398 passed, 20 failed. The same 20 fail on an unmodified working-1.6 checkout on this machine. They need a FOG install (/opt/fog/sessions, generated config).
  • phpstan, tests pass: no errors. Main pass: the same 3 errors in src/Base/FOGBase.php as an unmodified checkout here, none in the changed file.
  • KVM: a fresh 1.5.10.2518 (stable c97e205), one image captured, then rc-1.6.0 at 4983c25 with this change applied, installfog.sh -y --channel rc. Result: one pass, Updating Database...OK, Setup complete, vValue 445, no fog_schema_update_error.log. The 1.5 image deploys from the upgraded server, and the clone carries the source's marker file.
  • The table and column structure after that upgrade matches the two-pass upgrade without the change. Against a fresh RC-19 install, the only difference is users.uName and users.uCreateBy, carried from 1.5 (noted in RC-19 test report: upgrade from 1.5.10.2518 fails on the first pass (schema 290), and a rerun deletes the 1.5 web backup #2000).

🤖 Generated with Claude Code

A 1.5.10.2518 server arrives at vValue 288. 1.6 fills positions 287 and
288 with CREATE TABLE fileDeleteQueue and its first ALTERs, so an upgrade
skips them and step 290 ALTERs a table that is not there: 1146. That code
is not tolerated, so the update stopped. The reconcile after the loop then
created the table, but the installer had already printed "Failed!" with
the server left at 289, and only a second run finished the upgrade.

On 1146, run SchemaReconciler::reconcile() at the point of failure and
execute the statement once more. That is the second run's path, inside the
first. Any other error, a repair that fails, or a retry that still fails is
reported exactly as before.

Measured on a fresh 1.5.10.2518 (stable c97e205) upgraded to rc-1.6.0
at 4983c25: one pass, Setup complete, vValue 445, no
fog_schema_update_error.log, and an image captured on 1.5 deploys from the
upgraded server.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@mastacontrola
mastacontrola added this pull request to the merge queue Oct 28, 2026
Merged via the queue into FOGProject:working-1.6 with commit 0765e28 Oct 28, 2026
11 checks passed
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.

3 participants