Infinite loop during migrate script

[wpbullet]

I am running this on a store with 120k orders, the progress bar goes all the way to 100% but then it endlessly loops. Checking the top command shows PHP and MySQL processes continue to run so it seems to get stuck. Is there a --debug flag or something similar to help diagnose this?

I am happy to provide SSH root access to help figure this out :)

[stevegrunwell]

@wpbullet Thanks for reporting this; my goal is to get a good day or two on this plugin slotted into my workload this week, so I'll attempt to reproduce and get to the bottom of it!

[wpbullet]

beautiful @stevegrunwell I did do some additional digging and noticed there are 21000 meta_name dupes in postmeta so I am wondering if those are confusing the migration tool. I'm happy to provide access whenever you are ready :)

[stevegrunwell]

@wpbullet I'm digging into this, and thinking that it may be a duplicate of #42, wherein a user was experiencing a very similar result. When you stop the execution of the CLI command (or run wp wc-order-table count), you'll likely see "There are $x orders to be migrated."

If you run the following SQL query, does the result give you the same number as the $x orders to be migrated? If so, that likely confirms this CLI infinite loop being a result of the bug reported in #45 and fixed in #52:

SELECT COUNT(*) FROM wp_posts WHERE post_type = 'shop_order_refund'

[justlevine]

Not sure if I should post a new issue or not, as @wpbullet never followed up with his count results.
I'm also getting the infinite loop error, and there's not a single shop_order_refund on the site (99 total orders).

Running: Wordpress 4.9.6, latest versions of WC, wp-cli, and the -develop branch of this plugin, PHP 7.2.x (xampp windows 10).
(Also, I'm new to wp-cli, and woocommerce's database structure in general).

1. After the first error, I kept on running wc-order-table migrate with different batch-sizes until wc-order-table count eventually whittled down to 10. No change in batch size was able to get the number lower than that.

2. Then I ran migrate with --debug and batch-size=10, and got a list of all 10 order_ids that wouldnt migrate. Debug says all ten has been migrated. and then right after it throws the error. (Doesnt matter if I change the batch size to any other number, they list as migrated, and then the error is thrown, the number stays at 10.)

3. Next, I did a sql query to make sure only those ten orders in wp_posts didnt make it over to the new wp_woocommerce_orders:

SELECT `ID` FROM `wp_posts` WHERE post_type = 'shop_order' AND NOT EXISTS (SELECT * FROM `wp_woocommerce_orders` WHERE wp_posts.ID = wp_woocommerce_orders.order_id)

4. I compared all ten order's post_meta to a random different order that did migrate. They all looked pretty much identical.
   There are no duplicate order keys, orders, meta_keys (for the same order), or anything else.

PS: despite the successfully migrated orders appearing in the new woocommerce_orders table, its all still located in post_meta too. Not sure if this is by design of the script, or because the post_meta table is only cleaned up after all the orders migrate successfully.