problem

When a task is set to end, for example by Plunet through the API, the default workflow immediately drops the task materialized segment view. At nearly the same time end-of-task follow-up work can still be queued or running, especially PrepareReimportSegmentsWorker for saving task segments back into a TM and scheduled export workers. These workers read segments through the task materialized view. If the view was already dropped, the workers fail with errors such as E1169 and SQLSTATE[42S02] because LEK_segment_view_* no longer exists. 

This is a race condition and no general problem since in concrete case in general a MV check / recreate call is there, but:
CreateSnapshot -> SegmentsProvider -> FilteredIterator -> loadFirst() initially creates/checks the MV, but later loadNext() does not recheck. So a concurrent task-end drop can still break the snapshot during iteration.

That fits to the observed log sequence:

• task status changes to end
• PrepareReimportSegmentsWorker fails while creating the reimport snapshot
• SQLSTATE[42S02] reports the missing LEK_segment_view_* table
• shortly afterwards another process recreates the materialized view

The current immediate drop in editor_Workflow_Default_TaskHandler therefore creates a race between task finalization cleanup and required end-of-task background processing.

solution

Stop dropping the task materialized view directly in editor_Workflow_Default_TaskHandler when a task reaches STATE_END. Keep the view available for the queued finalization workers that still need it.

Move cleanup responsibility to the existing daily materialized-view cleanup path and enhance it so that materialized views of ended tasks are dropped with a hardcoded lifetime of one day, while active tasks still use the configured lifetime resources.db.matViewLifetime. And the cleanup must only drop an ended task's materialized view when no scheduled, delayed, queued, or running workers for that task still require the view.