Elasticpress: Stuck in an infinite sync state after an error during indexing

[emmerich]

Describe the bug

After running the index command and receiving a PHP error (such as bad syntax etc.), ElasticPress is stuck in a syncing state.

Steps to Reproduce

1. Create a function somewhere in PHP that causes an error. This was my example:

function prepare_post_for_indexing($post_args) {
  $post_args->set('meta', array());
  return $post_args;
}
add_filter( 'ep_post_sync_args', 'prepare_post_for_indexing', 1 );

1. Run wp elasticpress index --setup
2. You'll receive an error for the function you've created (which is normal, it's incorrect)
3. Correct the error (remove the function)
4. Run wp elasticpress index --setup again
5. You'll receive an error "An index is already occuring. Try again later." and there's no way of getting out.

Expected behavior
Indexing that causes an error should cancel the index operation so that a new one may take place.

Screenshots
Dashboard will also show a sync in progress, but with no option to cancel.

Environment information
ElasticPress master
ElasticSearch 6.4
WordPress 5.2.1

[emmerich]

After a quick check of the database, it seems that the transient value ep_wpcli_sync is set to 1 and not set back to 0. Thus it's line 1177 in Command.php which throws the error.

For those with this error, you can manually set ep_wpcli_sync (_transient_ep_wpcli_sync in wp_options) to 0 in the database.

[tlovett1]

@emmerich you are 100% correct. As far as I know, there isn't a consistent way to detect fatal error/forced script termination without custom PHP packages. Open to ideas if you have any.

[emmerich]

I'll admit PHP isn't my strongpoint, so I'm not sure either. It's quite a rare case and usually only happens during development, maybe having a WP CLI command to reset the ep_wpcli_sync state would be good enough?

[barryceelen]

Just a note for anyone running into this issue (like me): wp transient delete ep_wpcli_sync will enable you to run a sync again.

@tlovett1 do we need an elasticpress-specific cli command to do this? Alternatively we could add a suggestion to the error message, as it is not immediately apparent that you'd need to clear a transient to get back up and running again if the indexing process terminates unexpectedly.

[tlovett1]

@barryceelen seems like a sync reset command would be good. Want to create a PR?

[Trisky]

Hi there, this is the first result on Google when you search for the error message.

@emmerich you are 100% correct. As far as I know, there isn't a consistent way to detect fatal error/forced script termination without custom PHP packages. Open to ideas if you have any.

in plain PHP we can do

 function myfunc() {
    try {
        $this->indexPosts();
    } finally {
        $this->delete_transient();
    }
}

So every time indexPosts throws an exception or finishes successfully, it will call delete_transient() so the indexing is labeled as 'not running' again.

I think that a PR with this approach would solve the issue in a more graceful way than having a reset command.
Should I try it out?

[mi-um]

After a quick check of the database, it seems that the transient value ep_wpcli_sync is set to 1 and not set back to 0. Thus it's line 1177 in Command.php which throws the error.

For those with this error, you can manually set ep_wpcli_sync (_transient_ep_wpcli_sync in wp_options) to 0 in the database.

If someone is just looking for a quick way out, this helped me (using the WP CLI command):

wp eval 'delete_transient( "ep_wpcli_sync" ); delete_option( "ep_index_meta" ); delete_site_transient( "ep_wpcli_sync" ); delete_site_option( "ep_index_meta" );'

[oscarssanchez]

Closing as it seems this got resolved

@Trisky please feel free to submit a PR, thanks!