Why is my TYPO3 Symfony command able to add new objects to repositories but not update existing ones depending on the project instance?

Question

the question does indeed seem a bit odd, but let me explain. Also I'm not sure about some of the tags of this question.

We have a TYPO3 10 project in which we are using EXT:news as means to manage and display events. The News model has already been extended by some other extension, which adds properties that define a start as well as an end day and time. Only recently we started or rather wanted to start using EXT:calendarize and EXT:calendarize_news to be able to display those events in an interactive calendar. To save the need to manually manage EXT:calendarize Configurations for each News object I decided to implement a schedulable Symfony command to do that.

For both steps adding a new Configuration object to the database, and updateing the News object with the new configuration, I decided to go with the respective repository's functions and calling \TYPO3\CMS\Extbase\Persistence\Generic\PersistenceManager's persistAll() after each one. Each repository and the persistance manager are fetched by an \TYPO3\CMS\Extbase\Object\ObjectManager instance.

The problem we do not understand: The new Configuration objects get properly persisted, but the updates to any News object may or may not work depending on the system we're running the command on

• local development environment: no issues, everything works as intended (docker-setup)
• staging environment: works after flushing the cache (currently not able to reproduce)
• production environment: does not work at all.

What I mean by "does not work" is that even though each News object's _isDirty()-check returns TRUE after assigning (ObjectStorage::add) the generated Configuration object, the assignment does not get persisted leaving the database field NULL instead of the expected UID of the generated Configuration object

At this point, Ive debugged a little and the PersistenceManager correctly stores the changed News objects within its $changedObjects property and upon persistAll() removes them from there as it just creates a new ObjectStorage, and I'm not sure debugging into \TYPO3\CMS\Extbase\Persistence\Generic\Backend::persistObject will be of much help.

The problem does not seem to be code related, because it works on three instances (2x Develop, Staging) but not on the third (Production) which in itself seems oddly specific to us. Staging and Production share the same server.

What we've tried so far:

• verified the same php version (local <-> server)
• verified the same MySQL version (local <-> server)
• verified the spl_object_id of the PersistenceManager (EXT:news NewsRepository, EXT:calendarize ConfigurationRepository and the one gotten from the ObjectManager) (all three)
• executing the command via CLI and scheduler BE module (all three)
• using the same TYPO3_CONTEXT (Production) locally and on staging, thus using the same TYPO3 configs, to try and reproduce the issue in a more debuggable environment (to no avail)(local, staging)
• verified each News object is dirty after assigning the corresponding persisted Configuration object (all three)
• checked any logs for potential errors (none found) (all three)
• testing on another development machine (successful)

I also tested stepping away from the NewsRepository::update() and using a \TYPO3\CMS\Core\Database\Connection object which in turn executes a MySQL-query. This approach does indeed work.

Still, we'd like to understand the issue with the repository approach. Any clues, hints or thoughts on why this may or may not work are appreciated.

If you need more information on anything, please, feel free to ask.

Reminder: From our understanding the issue is not "Hey, this generally does not work", because it does on at least three completely independent systems. It's more of a "It does work, but not on Production and we couldn't figure out, why that's the case.".

After reading this again I'm not sure if some of the used tags really fit the question, but I'll leave them for now.

Best regards

Lukas