PHP Notice during cron related to Sync
dd32 opened this issue · comments
Impacted plugin
Jetpack
Quick summary
During WordPress cron, the following PHP Notice is often hit:
E_NOTICE Undefined offset: 1
URL https://example.orgwp-cron.php?doing_wp_cron=timestamp
File wp-content/plugins/jetpack/jetpack_vendor/automattic/jetpack-sync/src/modules/class-posts.php:391
Stack Trace do_action_ref_array('grunion_scheduled_delete'), WP_Hook->do_action, WP_Hook->apply_filters, Automattic\Jetpack\Forms\ContactForm\Util::grunion_delete_old_spam, wp_delete_post, delete_metadata_by_mid, do_action('deleted_post_meta'), WP_Hook->do_action, WP_Hook->apply_filters, Automattic\Jetpack\Sync\Listener->action_handler, Automattic\Jetpack\Sync\Listener->enqueue_action, apply_filters('jetpack_sync_before_enqueue_deleted_post_meta'), WP_Hook->apply_filters, Automattic\Jetpack\Sync\Modules\Posts->filter_meta
Steps to reproduce
Unknown.
A clear and concise description of what you expected to happen.
No response
What actually happened
No response
Impact
Some (< 50%)
Available workarounds?
There is no user impact
Platform (Simple and/or Atomic)
Self-hosted
Logs or notes
No response
Hi @dd32!
I see this looks to be happening for you when grunion_delete_old_spam is triggered by cron. I have not been able to replicate and even do some tests manually calling the function and deleting some posts have not incurred in the notice in my local server. If you could provide some more details on replicating or maybe get some error logs with the content of the args in filter_meta I'd appreciate it.
In any case, I have created #37817 which should take care of the issue by adding checks that ensure the array is well formed.
Unfortunately due to these being triggered in the delete action, I'm unable to inspect the data after the fact, and I haven't attempted to manually replicate it.
The logs I have access to don't include any stack traces other than what's shared either.
Technically #37817 would resolve it, but I don't necessarily think that's the best route forward, unless it's expected inputs that cause it. I don't think just removing the notice without understanding the cause is always the correct choice - sometimes it's "obvious" but this is one of those cases where it doesn't quite make sense why it's happening, and so, I'd personally err on the side of figuring that out instead.. even if it means the notice remains for months..
Hi @dd32!
I agree with you about the solution not being the more elegant.
I did try to replicate without luck (Details here p1718270572657889-slack-C011BCGRMBR)
Would it be possible for you to add logs on filter_meta since in the summary you stated that you have seen the PHP notice often hit? This way we might be able to pinpoint the issue :)
I can probably add a hook to jetpack_sync_before_enqueue_deleted_post_meta and observe it at that point, leave it with me!