Bug #99401
closed
#1381512761 TYPO3\CMS\Core\Type\Exception\InvalidEnumerationValueException Invalid value "-1" for enumeration "TYPO3\CMS\Core\Versioning\VersionState"
0%
Description
This happened after updating from 11 LTS to 12.1.3.
Steps to reproduce:- Have an database with pages having t3ver_state -1.
- Switch to a workspace
- Open Page module (Page Tree)
The exception happens within the Page Tree Ajax request and is not visible within the backend. Only a red notification will be shown.
A workaround that seems to work is to execute:
update pages set deleted = 1 where t3ver_state = -1;
I had the pages twice, with -1 and 1.
Updated by Christian Kuhn over 1 year ago
- Related to Task #96156: Remove obsolete VersionState constants added
Updated by Christian Kuhn over 1 year ago
- Related to Task #92791: Remove "new placeholders" in workspaces added
Updated by Christian Kuhn over 1 year ago
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.
I can images these scenarios:- 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?
Updated by Christian Kuhn over 1 year ago
- Status changed from New to Needs Feedback
Updated by Daniel Siepmann over 1 year ago
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
Updated by Benni Mack about 1 year ago
- Status changed from Needs Feedback to Closed
closing this issue now, docs PR is merged.