Cart items deleted without invoking the cart manager in the order postDelete do not delete referenced registrations

Will take a look within the next few days. Would like to have a PHPUnit test covering this case, but tests involving cron are non-trivial. There are some in the base Registration module if you decide you want to have a crack at it. Otherwise I am happy to add the test to your MR.

Thanks John. I am not sure we need the test to use the CRON. The CRON just runs a services to queue expired carts for deletion and the queue worker just uses the storage to delete them, so we could test by just deleting the carts programmatically. We can update the "steps to reproduce" to include "programmatically delete a cart" if you would like. I can write a test for that as time permits.

That makes sense, thanks. There are tests in CommerceRegistrationCartTest that cover this general area - if you want to, throw a test in there within the next couple of days, otherwise I'll add it this weekend. Either way I'll plan on getting this work committed soon.

@jon.oltman. I have added some test coverage now, so assigning back to you. Thank you.

Committed to dev branch and will be in the next release. Thanks for the work!

Thanks from me as well. Two customers' registrations were afflicted. I had to delete manually two dangling registrations that blocked new attempts to register because the particular event can only be booked once by the registrant.

A question remains: As I rarely check the site's status report, administrating almost everything with composer and drush, I saw only today an error stating there were "Mismatched entity and/or field definitions" in 7 entities: Order, Product, Product Variation, Actions, Coupon, Shop, and Content, stating that one field in each of them, these 7 fields all uniformly named "deleted" ("gelöscht" in German), needed to be deleted. I searched the web and found this command with the result below:

MariaDB [mydatabase]> select * from key_value where name = "field.field.deleted" or name = "field.storage.deleted" ;
+------------+-----------------------+--------+
| collection | name                  | value  |
+------------+-----------------------+--------+
| state      | field.field.deleted   | a:0:{} |
| state      | field.storage.deleted | a:0:{} |
+------------+-----------------------+--------+
2 rows in set (0.006 sec)

And two more commands from another site about mismatched definitions yielded this:

MariaDB [mydatabase]> SELECT * FROM `field_config` WHERE `deleted` = 1 ;
ERROR 1146 (42S02): Table 'mydatabase.field_config' doesn't exist
MariaDB [mydatabase]> SELECT * FROM `field_config_instance` WHERE `deleted` = 1 ;
ERROR 1146 (42S02): Table 'mydatabase.field_config_instance' doesn't exist

I am not versed in SQL and wouldn't know how to proceed, but could it be that cruft from the two failed orders with manually deleted dangling carts be the cause of the error? And how can this possibly be fixed?

I wouldn't even know how far to roll back the DB because the errors could have appeared weeks ago, most probably at some point during the D10.2 period, besides new registrations have come in that would get lost in a rollback. I am sure I always performed database upgrades when required; drush updbst was always clean afterwards. Upgrading my testing instance from 10.2.7 to 10.3.1 didn't change the error. I also couldn't say whether it was present before the most recent commerce update of some weeks ago, and I didn't find a similar report in the Commerce Core issues.

Sorry for the noise. My recent composer.json backups reminded me of an install of the project "drupal/trash" which I decided not to keep installed. I had just "drush-uninstalled" but not "composer-removed" it. Therefore the fields' names had rightly so a label "deleted" in them, which was misleading for me. Properly re- and de-installing the module removed the error message from the status page.

Automatically closed - issue fixed for 2 weeks with no activity.