Otherwise, due to failures in projection or catchup-hooks the process would be immediately interrupted leaving a broken state.

For example a faulty redirect handler hook - that just listens to live events - would be called during publishing.
That means the remaining part to publish is already commited and we know we still have work to do to fork the new user content stream and apply the remaining.
But the catchup hook would interrupt immediately when the events were catchup'd live.
We would be left with a CLOSED user content stream that contains the "same" events that went live during the rebase. Reopening would not help at that point.
This is why we must ensure that all events are published BEFORE we do the first catchup.

Further implications:
- running catchup only once should be more performant
- we cannot refetch the current content stream version for what where previously "subcommans" (`forkContentStream`) but we must pass $expectedVersions around from the outside
- we should not run constraint checks after the first `yield` as that would still operate on the old state. Thus all checks are combined above

…re-contentstream-not-closed

…ring publication

... and a ConcurrencyException is thrown

Introduces a `WorkspacePublicationDuringWritingTest` parallel test (with own cr) to assert that behaviour.

That allows us to use the same content repository. Previously a super slow paratest would lead that another testcase will already be started and its setup then run twice at the end.

paratestphp/paratest#905

… version instead

Also readd lost documentation and simplifies the `handle`

The ->throw logic was initially introduced via

neos#5315

but then removed again as we thought it was no longer needed.

…re content stream is never left closed

During the beta phase it can happen that user forget to apply a migration to migrate the stored commands in the even metadata, upon publish this would close the content stream and fail directly afterward.

Applying the migration then would not be enough as the content stream is a closed state and has to be repaired manually.

Event thought this is not super likely, its not unlikely as well and the case during publication were we rely on things that might not be that way.

As an alternative we could discuss doing the closing after acquiring the rebaseable commands.

… many edge cases

Alternative fix for d27f83f

Previously an error in `extractFromEventStream` because the payload was not correct and yet has to be migrated would lead to a closed content stream which is of course persisted even after fixing the events via migration.

This is still save to do, as the `closeContentStream` will commit the close on the FIRSTly fetched expected version.

Same guarantees, different error behaviour in rare cases.

;)

;)

…ace is still the original content stream

…re-contentstream-not-closed

…have :))