TYPO3 Core

Here is the thing:

t3ver_state = -1 has been removed in v11.

Upgrade wizard row updater 'WorkspaceNewPlaceholderRemovalMigration' / 'Scan for new versioned records of workspaces and migrate the placeholder and versioned records into one record.' takes care of a migration and sets affected rows deleted = 1. See #92791.

Constant VersionState::NEW_PLACEHOLDER_VERSION = -1 has been removed in v12 with #96156 since there shouldn't be records with this state anymore. VersionState now throws an exception if it stumbles upon such a record since it can't enum it anymore.

• The row updater was not executed at all.
• The row updater was executed but something still created a new t3ver_state=-1 record.
• The row updater is buggy (but it looks pretty straight).

All in all I'm unsure if we should change this in core: It would mainly mean that we re-introduce the constant in v12 and may have to deal with that state at various unknown places. We probably don't want this since we don't know anymore what would happen with such rows throughout the core. In case the updater is buggy, which I doubt, we should of course fix it, though. Other than that, v12 core should assume there aren't any such rows anymore.

As such, @Daniel Siepmann and @Benni Mack - could you maybe check if you executed these row updaters and maybe re-run them to see if that fixes the issue?

Apart from that, this could also be turned into a health check for ext:dbdoctor - maybe not following the migration logic, but fully removing such rows assuming the row updaters have been executed. I could open an issue in dbdoctor to check these scenarios (along with pid=-1 and t3ver_state=3 records, those from the v10 and the other v11 row updater). I created https://github.com/lolli42/dbdoctor/issues/25 to remember this.

What do you think?

Hard to guess what has caused the invalid rows. Wild guess would be some none working query with SQLite which I've used back then.

I won't suggest to change anything within the core. Instead, I would add info to the docs.typo3org page for the exception. PR can be found here: https://github.com/TYPO3-Documentation/TYPO3CMS-Exceptions/pull/98

dbdoctor handles this now.