Orders which fail an initial import become "stuck" in an Error state

[StevenWolfe]

When an Order fails to be imported to Magento the Order Sync screen shows a "retry" action for the order; however if the reason for the initial error is within the order's JSON data (and not an internal magento exception) then the retry task will always fail, leaving these orders stuck.

This is because the order's JSON is serialized and persisted within reverb_process_queue_task_unique.serialized_arguments_object in the Magento database. This serialized data is never refreshed.

The retry action should retrieve an updated version of the order via the API and use that during it's retry action. This would address cases such as orders where the buyer has not yet provided a shipping address (see #144).

We've worked around this by manually updating the serialized_arguments_object.

As a side note: it would be nice if the serialized arguments were in JSON rather than PHP's binary strings, which are . It would be easy to convert these in a migration script with json_encode(unserialize($blob)) call, especially since the column is already a text field.

[skwp]

That seems reasonable

Sent from my iPhone

On Nov 6, 2015, at 1:04 PM, Steve Wolfe notifications@github.com wrote:

When an Order fails to be imported to Magento the Order Sync screen shows a "retry" action for the order; however if the reason for the initial error is within the order's JSON data (and not an internal magento exception) then the retry task will always fail, leaving these orders stuck.

This is because the order's JSON is serialized and persisted within reverb_process_queue_task_unique.serialized_arguments_object in the Magento database. This serialized data is never refreshed.

The retry action should retrieve an updated version of the order via the API and use that during it's retry action. This would address cases such as orders where the buyer has not yet provided a shipping address (see #144).

We've worked around this by manually updating the serialized_arguments_object.

As a side note: it would be nice if the serialized arguments were in JSON rather than PHP's binary strings, which are . It would be easy to convert these in a migration script with json_encode(unserialize($blob)) call, especially since the column is already a text field.

— Reply to this email directly or view it on GitHub.

[dunagan5887]

@skwp It would make sense for us to provide a button on the task's page which re-fetched the json from Reverb upon manual interaction by an admin

@StevenWolfe in terms of serialize() vs json_encode(), serialize() allows for more robust functionality as it can encode numerous different types of objects, where as json_encode() only decodes to a stdClass object. At this point it's a bit late in the process to change to json_encode()

[StevenWolfe]

@dunagan5887 no biggie, was just a thought while I was wiring up a harness to poke the updated data in

[StevenWolfe]

@dunagan5887 one other thought - is the serialize()'d data safe in a text column? I'd thought it was a byte array, or a mashup of strings and some binary gunk.

[dunagan5887]

Given our use case for the objects, it should be safe in a TEXT field. Nonetheless, it does appear that a BLOB field is recommended for this field. I'll create an upgrade script to convert this field to BLOB just to be safe