Repair the schema manifest, and keep a FOS report readable after its task

[mastacontrola]

Two follow-ups on the FOS report feature (#1206–#1223).

1. schema-expected.php had drifted, silently

407be1a added logType and logText to taskLog's create string and not to its columns array. The file header asks nobody to hand-edit that block; nothing checked that they agreed.

SchemaReconciler::plan() pass 3 adds missing columns only from columns, and skips a table whose columns is empty — so the reconciler could never heal a taskLog that already existed, and an existing table is the only kind it repairs.

The failure is quieter than it looks, and not strict-mode dependent. Naming a column that doesn't exist is error 1054, on any sql_mode. And nothing throws:

Expected	Actual
PDODB::query() throws	$throwOnQueryError is false and nothing sets it true — it records ->error and returns
TaskError's catch writes "unusable report from FOS"	Never fires. save() catches its own insertId=0 exception and returns false; _logRow() ignores the return

So the endpoint answered its usual 200 ##, fosreports.log got the normal success line, the task was marked Failed, HOST_IMAGE_FAIL fired — and the report simply was not in the database. PDODB's own error() writes to a file gated on FOG_LOG_ERROR, which is 0 by default, so the SQL error went nowhere at all.

Proven by shadowing taskLog with a TEMPORARY table of the six old columns:

save() returned: false
DB->error: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'logType' in 'INSERT INTO'
rows now in shadow taskLog: 0

Second consumer, same gap: OpenAPI::_entitySchema() reads column types from columns, so the published API document described both fields as "No type information available for this column." Fixed as a side effect.

Audited all 67 tables in both directions and on the definition text. taskLog was the only divergence. Corrected in place rather than regenerated — regeneration rewrites 67 create strings and 507 column definitions from whatever the generating server has, which is not a reviewable diff for a two-column bug. Verified the edit is byte-identical to what schema-manifest.php generate produces.

Guards, since "nothing compared the two blocks" was the actual defect:

• tests/schema-manifest-consistent.test.php — compares them for every table, both directions and the definition text. No database, so it gates CI. Mutation-verified against all four ways they can disagree.
• bin/schema-manifest.php now refuses to write a table it parsed no columns for. It can't disagree with itself today, but the two blocks come from one $raw by different means and only the column parse can fail quietly — a SHOW CREATE TABLE shape that regex stops matching would ship every columns block empty and disable the reconciler for the whole schema.

2. A report lost its identity when its task was cleared

taskLog stores no host and no task type of its own. Nothing deletes taskLog rows — but Route::deletemass('host') cascades to task, and taskLog is in no cascade at all. Deleting a host destroys its tasks and leaves the reports with NULL where the host name was, at the same moment the host row that could have supplied it goes. On the install this was written against, 9 of 56 rows were already orphaned.

Narrower than first stated: taskLog stores taskStateID itself, so state survives; the image was never in this view. What is lost is host name, host id and task type.

Schema 341 copies logHostID, logHostName and logTaskTypeName onto the row at write time and backfills reports whose task still exists. _logQueryFrom() prefers the copy, falling back to the joins for pre-341 rows and state rows. That order is deliberate: a report is a historical record, so the name the host had when it failed is the answer, not what it has been renamed to since.

Why not block deleting a task that has reports: it inverts the dependency — a diagnostic artifact would constrain operational cleanup — and to be consistent it would have to block host deletion too, since that's the path that actually removes tasks. Refusing to delete a host because it once failed to image is a worse product than losing a host name.

Only the FOS report endpoint fills the columns. 53 of those 56 rows are state transitions written on every transition; they mean nothing without their task, and three extra lookups per transition buys nothing — the same reasoning that gave logText no value on a state row in step 338.

Two column shapes, following what the writer can actually produce: save() omits an unset optional column whose key ends in id, so logHostID lands NULL, but writes '' for every other unset field (the trap step 340 had to repair for logType).

logHostID still comes from the hosts join, because the grid links the name with it and a link to a deleted host is worse than no link. Resolving that join through the stored id first keeps the link working once the task is gone but the host is not.

Tests

tests/tasklog-report-retention.test.php drives the writer against a fake connection, and with FOG_TEST_DSN runs the real statement over six shapes:

Fixture	Asserted
task alive, host alive	reads as it always did
task deleted, host alive	keeps name, type, icon — and still links
task deleted, host deleted	keeps the name it had, offers no link
pre-341 row	still resolves through the joins
state row	still resolves its state
host renamed since	keeps the name it was written with

Seven mutations verified. It needs no CREATE DATABASE, so an ordinary FOG database user can run it.

Also fixed, found on the way: tests/schema-executes.test.php walked the manifest's top level instead of ['tables'], so it collected no manifest statements and failed its own non-empty guard whenever a DSN was set — that half had never run. It now also skips cleanly when the account may not CREATE DATABASE instead of dying on an uncaught PDOException.

sh tests/run-all.sh — 80 passed, 0 failed, with and without a DSN.

Downstream

None — no route class added or removed.