data: a failed CREATE VIEW is recorded CREATED-with-error and never retried - a view over a later-published module's tables stays missing for good

[delchev]

Symptom

Publish a project carrying a .view whose SELECT references another project's tables, then publish that other project. The view's CREATE VIEW fails on the first synchronization pass (Table "X" not found) - and is never attempted again: every later pass (including the ones that create the missing tables moments later) skips it, and every consumer of the view fails from then on (Table "<VIEW>" not found) while publish returns 200 and the log stays quiet after that single first error.

Hit in practice with the #6938 generated report views (an intent module's <Report>Lines.view selects from a cross-model owner's table), publishing the report module before its owner. Boot-time deployments don't hit it - one pass processes every module's tables (SynchronizersOrder TABLE=220) before any view (VIEW=230) - it is specifically the incremental-publish flow.

Cause

ViewsSynchronizer.completeImpl, CREATE phase:

try {
    executeViewCreate(connection, view);
    callback.registerState(this, wrapper, ArtefactLifecycle.CREATED);
} catch (Exception e) {
    callback.registerState(this, wrapper, ArtefactLifecycle.CREATED, e);   // <-- CREATED, with error text
}

The failure is registered as CREATED (with the error message attached). On the next pass the CREATE branch is gated on ArtefactLifecycle.NEW and the UPDATE branch on MODIFIED - a CREATED artefact matches neither, so the failed view is permanently parked. The only ways out are changing the .view content (checksum -> MODIFIED -> executeViewUpdate recreates it) or dropping the database.

Same class as #6542 (csvim: failed imports not retried until the checksum changes) - a definition whose processing failed for an environmental reason stays failed after the environment heals.

Ask

A failed executeViewCreate should leave the artefact in a state the next pass retries (e.g. keep it NEW / mark it FAILED-and-retryable), so a view over tables that arrive one publish later heals on the pass that creates them - matching how the topological retry already behaves inside a single pass. The error should also surface as such rather than reading as CREATED in the artefact state.

(Workaround meanwhile, for anyone who hits it: touch the .view file - any content change - and republish; the MODIFIED path recreates the view.)