Closed viavacavi closed 3 years ago
Update: Found this mws documentation stating that up to 200 items can be added through CreateInboundShipmentPlan: https://docs.developer.amazonservices.com/en_UK/fba_guide/FBAGuide_CreateShipment200Items.html
Can anyone confirm my results? I can't seem to get any more than about 20 SKUs to work properly.
From the top of my head, I'm pretty sure a lot of the calls are limited to batches of 20 - this is the case for a few of the endpoints.
@Bobspadger that was my initial thought too, but the above link clearly states a recommendation (not even limit) of 200 skus per request. In my own tests, the number of skus that I can successfully create a shipment plan with varies from 25-28 depending on the request. There appears to be an issue with python-amazon-mws or urllib.
Looking at the trace though, this is a 400 error from Amazon - suggesting the issue is starting there.
Now, this could be because of a badly formatted input (our issue) or that there is too much data being sent, or, what I have seen before is the URL is too long.
Are you able to capture the full request, and the response (these are available on the return from the API)
If you need to XXX out various bits for security thats cool but I think it will help us find the source of the issue.
Amazon often return more precise errors in the xml
they return
Ok, I have done a ton of debugging and research today. Here is what I've found:
Using the MWS scratchpad, I can definitely create a shipment plan with a large number of skus:
However, look at the 400 response:
This shows that a response(400) is a valid amazon response, and this is where the problem lies with the python-amazon-mws code. The response (400) means "This operation may be partially successful...", and is a flag for the programmer to check the XML response for errors that may have happened during the transaction. However, python-amazon-mws treats the response 400 as an exception and bombs out. Further complicating this, the response dictwrapper isn't even set, so the programmer can't even see what the issue may have been.
The correct way this should be handled is that response(400) should be allowed as perfectly valid, and the response dictwrapper should be set the .response key appropriately so that the programmer can decide on how to act on it instead of the program just bombing out on an MWSError exception
in my own code that has not been working, response(400) has been returned because one of my SKUs has a COVID-19 restock limitation. Again, this should be perfectly valid as the rest of the SKUs are added to the plan as they should (the operation was "partially successful) - the response XML is just notifying the programmer that one of the SKUs weren't added per the request.
Here is a section in the MWS docs regarding error handling: https://docs.developer.amazonservices.com/en_US/dev_guide/DG_Errors.html
Whenever I run my script it doesn't seem to POST to Amazon's System. I am not getting any errors; I just don't know why it's not uploading the shipping plan. When I run it through MWS scratchpad its response is 200, so I'm not sure where my this is breaking down for me.
@cajohn2757 Only plans created through the Seller Central interface appear online. You will have to process the response from create_inbound_shipment_plan to create the individual shipments
If you want to have a shipping plan show up in seller central, you can instead use the Feeds API with _POST_FLAT_FILE_FBA_CREATE_INBOUNDPLAN
Ok, I have done a ton of debugging and research today. Here is what I've found:
- Using the MWS scratchpad, I can definitely create a shipment plan with a large number of skus:
- However, look at the 400 response:
- This shows that a response(400) is a valid amazon response, and this is where the problem lies with the python-amazon-mws code. The response (400) means "This operation may be partially successful...", and is a flag for the programmer to check the XML response for errors that may have happened during the transaction. However, python-amazon-mws treats the response 400 as an exception and bombs out. Further complicating this, the response dictwrapper isn't even set, so the programmer can't even see what the issue may have been.
- The correct way this should be handled is that response(400) should be allowed as perfectly valid, and the response dictwrapper should be set the .response key appropriately so that the programmer can decide on how to act on it instead of the program just bombing out on an MWSError exception
- in my own code that has not been working, response(400) has been returned because one of my SKUs has a COVID-19 restock limitation. Again, this should be perfectly valid as the rest of the SKUs are added to the plan as they should (the operation was "partially successful) - the response XML is just notifying the programmer that one of the SKUs weren't added per the request.
Here is a section in the MWS docs regarding error handling: https://docs.developer.amazonservices.com/en_US/dev_guide/DG_Errors.html
Cool - thats fantastic work. Thanks 👍
I'll try to take a look at that part of the code ASAP
Deleted my prior response as I re-read the convo, and what I stated before didn't seem relevant.
While it's true PAM could be more graceful about handling these errors, in my experience the "partially successful" error response is dubiously named. You need the successful response from create_inbound_shipment_plan
in order to make use of the plans it generates. If the only response is an error, then essentially the entire request has failed: you have to remove the offending SKUs from the payload and try create_inbound_shipment_plan
again with valid SKUs only, or they won't generate a shipment plan for you.
I have not tested extensively with HTTP400 errors in the response payload in the new code we've been working with, but it's definitely something we need to check for. I do know that requests
will to a raise_for_status
call on the response and raise some exception for any 400 error; and PAM would not capture that exception properly to then parse the error.
Something I'll have to check for in the next sprint when I have some time over the next few weeks, though. Appreciate the work you've done debugging the issue, @viavacavi :)
@GriceTurrble I agree, it's a very strange choice Amazon has made with the HTTP400 error in these cases. In any case, PAM should definitely let the programmer handle this type of error handling, as without the XML response from Amazon there is no way to know what is causing the crash. For now I'm just going to eliminate the try/except block around HTTPError in make_request so that I can keep pushing forward in my code. Perhaps the exception should only be thrown on an HTTPError in which no XML response is recieved.
Thanks for your attention on this, PAM is an excellent project. I'm quite familiar with the MWS API, so hopefully I can help out when/where possible (I'm still a bit new to Python, but I'm advancing pretty well)
This is a continuation from issue #214
I'm currently trying to use the InboundShipments API, specifically create_inbound_shipment_plan() This is using the current Develop branch, running on Python 3.8 on Ubuntu 20.04
The above code with 2 items works (with an XML response stating the SKUs don't exist obviously). However, I'm having issues with more complicated lists of items. The item generation below with 60 items fails:
With attempts to create shipping plans with a large number of items, I get a variety of errors, ranging from: HTTP Error 400 Error 405 which returns HTML (not XML)
We have over 300 SKUs on Amazon, so our shipping plans can be pretty large. Looking over the MWS developer API documentation, I don't see a stated limit on the number of items that can be added with create_inbound_shipment_plan(). I'm not sure if the issue is on Amazon's end, python-amazon-mws, or urllib.
Here is an example error from trying to add 30 items: