action-scheduler
action-scheduler copied to clipboard
woocommerce
Error saving action: `ActionScheduler_Action::$args` too long
Closes #851
PHP Fatal error: Uncaught RuntimeException: Error saving action: ActionScheduler_Action::$args too long
Hi @barryhughes ,
Thank you for taking the time to look at the issue.
Thank you for suggesting the hash method. It's possible to use that method, but it seems like a band-aid solution. The solution does work, however.
My main reason not to use the hash method is that instead of storing the Action Scheduler's related $args into its table, it's forcing us to store it in the postmeta or options table. It will pollute the tables meant for posts or options/settings. Another reason is the cleanup of past/failed/successful scheduled actions isn't going to drop related records from these tables in case the action failed to complete (like the action threw a fatal error during the process). At least deleting a record from AS tables will remove that data too.
Based on your comment above, I've updated the schema to 7 and added all the necessary code. The $max_args_length validation still exists but increased to store approx. half the length of the longtext field, which I believe should be sufficient enough for several cases, including at scale sites.
Please let me know if anything else needs to be updated.
My main reason not to use the hash method is that instead of storing the Action Scheduler's related $args into its table, it's forcing us to store it in the postmeta or options table.
Yep, I agree that wouldn't be ideal.
Though, my reading of the conversation ("you could keep args as json encoded/serialized in a new meta field") was not that we would necessarily depend on core WordPress tables to store the full length args (which, of course, is currently possible even without this change).
In any case, I wanted to let you know we haven't lost sight of this change—but there are a few other items we're prioritizing right now, so there might be a further delay before we can really tackle this one.
Following up to add 2¢ that I for one would appreciate seeing a robust solution for longer stored values to improve performance and stability relative to the hash method mentioned above. Thanks to all.
