Give a FOS report somewhere to live: taskLog and a log of its own (schema 338)

[mastacontrola]

#1207 gave FOS an endpoint to report an imaging failure to. It fired
HOST_IMAGE_FAIL and called error_log(), and that was the whole of it -- so a
report either reached a notification plugin or it reached the web server's
error log, mixed in with everything else the web tier writes, correlated with
nothing. Neither is a place an admin goes to ask "what did this task actually
say before it stopped".

A report now lands in three places:

a taskLog row, typed and with the text in it. This is the one correlated
with the task: it carries taskID and the state the task was in;
/var/log/fog/fos/fosreports.log, listed by the Log Viewer like any other
log because 'fos' is now in FOGLogPaths;
HOST_IMAGE_FAIL, as before -- errors only, imaging tasks only.

SCHEMA 338 adds logType (default 'state') and logText (NULL) to taskLog.
Every row in that table so far is a state transition, which is exactly what
the default backfills them as, so TaskingElement::taskLog() is untouched: a
state row costs no extra column. logText is NULL rather than '' so "no body"
and "an empty body" stay distinguishable. The step is a closure, like 336,
because ADD COLUMN has no IF NOT EXISTS below MariaDB 10.0.2 and a re-run has
to converge rather than error.

TYPES. FOS now sends type=error or type=warning, because handleWarning()
reports too (FOGProject/fos#152). A warning means the machine carried on, so
it is recorded and it does not fire the failure event -- announcing a failed
deploy for a task that went on to succeed would be worse than saying nothing.
A report with no type at all is an error: an older FOS reporting a real
failure must not be downgraded into silence.

The row is written BEFORE the imaging gate, so a failed Memtest or inventory
is recorded against its task even though no imaging event can fire for it.
That gate is still there for the event itself -- firing HOST_IMAGE_FAIL for a
non-imaging task is the defect #1202 removed, in the other direction.

THE LOG FILE gets its own subdirectory, created by the installer as the web
user with httpd_sys_rw_content_t. Both halves matter. It is not the top level
because $servicelogs is root's and holds the eight daemons' logs, and rotation
renames and unlinks -- the same split ADR 0010 made for the plugin runner. And
it is not created by PHP, because /opt/fog inherits usr_t and httpd_t may READ
usr_t but not write it (GH-964), so a directory made without the relabel looks
right and silently swallows every write on an enforcing host. error_log() is
kept as the fallback, not the destination: a server whose web tree is updated
but which has not been re-installed yet has nowhere to write, and a report
that reaches no log at all is the exact failure this path exists to end.

Rotation keeps one old copy at SERVICE_LOG_SIZE -- the daemons' setting, so an
admin who has already decided how big a FOG log may get does not decide again.
One generation rather than five: this file gains a line per failed task, not a
line per poll.

VERIFIED against a throwaway copy of a real FOG database in a container, with
the web tier served from a shadow tree, so nothing live was written:

step 338 applied through its own closure, backfilled all 52 existing rows to
'state', and ran clean a second time;
an error on a Deploy task wrote its row, its log line and fired
HOST_IMAGE_FAIL to a registered listener;
a warning on the same task wrote its row and its log line and fired nothing;
an error on a Memtest task wrote its row and its log line and fired nothing;
a report with no type was recorded as an error;
an embedded newline arrived flattened to spaces, as #1207 intended;
the file rotated to .1 once it passed SERVICE_LOG_SIZE.

The ip column is empty in those rows only because filter_input(INPUT_SERVER)
returns NULL under the cli-server SAPI the harness used; the same TaskLog
constructor fills it under php-fpm, which the 52 pre-existing rows show.

tests/task-error-report.test.php grows the type routing, the row's position
relative to both gates, the model mapping, the FOGLogPaths entry and the
installer's two lines. Every one of them was mutation-verified.

Downstream: none. tasklog is already a Route::$validClasses entry, so
OpenAPI picks the two columns up from the regenerated manifest.

---

Pairs with FOGProject/fos#152, which adds the type field and makes
handleWarning() report as well. Either side works without the other: an
older FOS sends no type and is recorded as an error, and a newer FOS talking
to an older server gets a 404 it already ignores.

🤖 Generated with Claude Code

https://claude.ai/code/session_013mJVe4CpK3rRbi9H5GubXd