Cron job issue

[Publisher1953]

In the last couple of weeks, we've been getting the message "

Some of your cron jobs did not run

. . . Specifically the daily cron job.

the other cron jobs seem okay.

The only change I can think of making of any significance is that in the last couple of weeks I've been pruning unnecessary and redundant "custom fields" within the various lists. Some of these field lists have grown extremely long and aren't used for any new list entries. (And for old entries, the data associated with these fields is uselesss, as well.)

My consultant reports this result when he tries to manually run the cron job:

his is the error i am seeing when attempting to run the daily cron command manually :

[2025-01-28 14:40:16] - Processing list id: 29
[2025-01-28 14:40:16] - Acquiring the mutex lock...
[2025-01-28 14:40:16] - Loading all custom fields for this list...
[2025-01-28 14:40:16] - [0] Loading subscribers set for the list with limit: 1000 and offset 0
[2025-01-28 14:40:16] - [0] Starting a new batch counting 1000 subscribers...
[2025-01-28 14:40:16] - [0] Field id 175 will add 740 records.
Error: Call to a member function getIsMultiValueField() on null in /home/mwmkt/public_html/mailwizz/apps/common/components/runners/SyncListCustomFieldsRunner.php:297

The error message seems to point to a problem with custom fields when processing synced lists, and list id with the issue appears to be: 29
Do you have any idea if we are using custom fields and is something we can edit or refresh/regenerate to bypass this error?
I am unsure if this is a result of the mailwizz update applied or if its a known bug:

Is there something I can do to correct this problem?

 

[twisted1919]

Can you check your mw_list_field_value table and make sure it has proper foreign keys on field_id and subscriber_id columns?
Because from the error you got, it seems somehow that table has orphaned rows, and it can only have orphaned rows if you don't have fk's on that table. And if you don't have on that table, please check other tables as well to see if this is a general problem or localised in that table.

 

[Publisher1953]

My consultant asks this question: "It does have the mentioned foreign keys, regardless, would restoring this table or a different table from a backup act as a workaround for this issue?"

 

[twisted1919]

It does have the mentioned foreign keys

Then you should not have this problem...
I am like 99% sure that table contains orphan rows that don't match list fields anymore.

would restoring this table or a different table from a backup act as a workaround for this issue?

No.