Replies: 35 comments
-
|
Totally agree with OP. This SP API design decision doesn't make sense and is a step backward. |
Beta Was this translation helpful? Give feedback.
-
|
Hello @johnkw Thank you for raising this issue! I am investigating the criteria for CANCELLED state and if DONE_NO_DATA status is no longer supported in SP API. Based on the investigation, I will work with respective teams to get more clarity regarding the status description in our API documentation and update it if required. Thanks, |
Beta Was this translation helpful? Give feedback.
-
|
Any updates on this issue? |
Beta Was this translation helpful? Give feedback.
-
|
this would be a good feature @ShivikaK |
Beta Was this translation helpful? Give feedback.
-
|
Seller Central Support has confirmed that this github bug is accurate, and is the place to look if it gets fixed. |
Beta Was this translation helpful? Give feedback.
-
|
Adding to this thread. I want to add that DONE_NO_DATA does not work properly in MWS and you will often get DONE_NO_DATA when they are really just cancelling the report because you requested it a few times in succession. Happens constantly trying to get clients order history... Also, new within SP API, FATAL also occurs when a report is cancelled (example: try calling GET_FBA_FULFILLMENT_CUSTOMER_RETURNS_DATA within a few minutes with a recent date range). From my perspective the following values would be ideal: ** AND ** x-amzn-RateLimit-Limit should be context sensitive to each report type since there is in fact some kind of report level throttling, not just the overall CreateReport throttle... |
Beta Was this translation helpful? Give feedback.
-
|
Is |
Beta Was this translation helpful? Give feedback.
-
|
This issue that has yet to be resolved, after several months, is the single reason why we cannot migrate to the SP API. Is there any update on this? Has anyone found a way to determine if a canceled report is due to an internal error, throttling, or no data? |
Beta Was this translation helpful? Give feedback.
-
|
It's a ridiculously scary hack, but for now we just assume any |
Beta Was this translation helpful? Give feedback.
-
|
A number of folks are commenting this makes things unusable, I'm not sure thats true. To me it behaves mostly in the same way as MWS does, and many large scale successful applications have been built there. What you have to do is build in appropriate retry logic and pacing. You consider any non "DONE" statuses as an error, and you retry those, with back-off timing, a few times. If you get 3 or four non-"DONE" statuses for the same report request parameters after retrying and ensuring you are not calling, for example, for 30 days of returns every five minutes, then you can assume it really means there is no data available for those parameters. |
Beta Was this translation helpful? Give feedback.
-
|
We're getting set to migrate to SP API, @kpconnell I think the approach you mention is the only option. Have you encountered any issues with this approach? |
Beta Was this translation helpful? Give feedback.
-
|
Is there any updates for this issue? Or, is there any workable solution in this case? |
Beta Was this translation helpful? Give feedback.
-
|
This is a very old issue that is probably not getting as much attention as it deserves. We encourage you to check if this is still an issue after the latest release and if you find that this is still a problem, please feel free to open a new issue and make a reference to this one. |
Beta Was this translation helpful? Give feedback.
-
|
The new documentation at https://developer-docs.amazon.com/sp-api/docs/reports-api-v2020-09-01-reference indicates this is still broken. |
Beta Was this translation helpful? Give feedback.
-
|
This is a very old issue that is probably not getting as much attention as it deserves. We encourage you to check if this is still an issue after the latest release and if you find that this is still a problem, please feel free to open a new issue and make a reference to this one. |
Beta Was this translation helpful? Give feedback.
-
|
The bot is correct though, that this issue is "probably not getting as much attention as it deserves." |
Beta Was this translation helpful? Give feedback.
-
|
Don't close this |
Beta Was this translation helpful? Give feedback.
-
|
As mentioned in the documentation cancelled state indicates the report was cancelled. There are two ways a report can be cancelled: an explicit cancellation request before the report starts processing, or an automatic cancellation if there is no data to return. As a requestor you would know the requests that you sent cancellation for and can filter these requests from the total cancelled ones to get the requests with no data. This is standard SP-API report behavior across all reports. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the explanation, @MeenaAmz. But the solution is not good. If the report has no data, it should return that -- |
Beta Was this translation helpful? Give feedback.
-
|
This is not accurate - There are also cancels for requesting the same
report as in "Cancelled you asked for this same report too many times" and
there are also Q4 "This report was cancelled because we are too busy"
…On Tue, Apr 30, 2024 at 4:28 AM MeenaAmz ***@***.***> wrote:
As mentioned in the documentation
<https://developer-docs.amazon.com/sp-api/docs/reports-api-v2021-06-30-reference#processingstatuses>
cancelled state indicates the report was cancelled. There are two ways a
report can be cancelled: an explicit cancellation request before the report
starts processing, or an automatic cancellation if there is no data to
return. As a requestor you would know the requests that you sent
cancellation for and can filter these requests from the total cancelled
ones to get the requests with no data. This is standard SP-API report
behavior across all reports.
—
Reply to this email directly, view it on GitHub
<#393>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIHBZU4ALO5PVKV7LJLRR3Y72UNNAVCNFSM47BWCLFKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBYGM3DANBUGY3Q>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Thank you for bringing this up. We have noted & forwarded this to the relevant team for review & action.
|
Beta Was this translation helpful? Give feedback.
-
|
@shreeharsh-a why wouldnt this issue be open until the issue is actually resolved |
Beta Was this translation helpful? Give feedback.
-
|
@jakeleventhal thanks for your question. Only issues related to the content published on this repo will be tracked to closure here. Anything else will need to be raised & tracked via Developer Support cases. |
Beta Was this translation helpful? Give feedback.
-
|
@shreeharsh-a I understand but this is something that I and probably dozens of others have raised in support tickets going back years. Surely there must be some publicly tracked issue list? |
Beta Was this translation helpful? Give feedback.
-
|
It's great that the SPAPI team has been informed of this bug report. However it would be helpful to leave the bug open until it's fixed, so people know where to look for information on this bug. Closing bugs that are not fixed is extremely counterproductive. We used to be able to search easily for the open bugs and when we hit them again could quickly refresh our memory on the status and what to try to do as a workaround. Now they can still be found via Google or more complicated github searches. But it's much easier to be able to search github.com for OPEN bugs when looking for bugs that are still actually supposed to be open because they're not fixed. |
Beta Was this translation helpful? Give feedback.
-
|
It is a content issue.. at a minimum the content should clarify the
multiple real meanings of the status enum.
…On Fri, 31 May 2024, 10:45 pm Shreeharsh, ***@***.***> wrote:
@jakeleventhal <https://github.com/jakeleventhal> thanks for your
question. Only issues related to the content published on this repo will be
tracked to closure here. Anything else will need to be raised & tracked via Developer
Support <https://developer.amazonservices.com/support> cases.
—
Reply to this email directly, view it on GitHub
<#393 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIHBZW2IIFGPODFWL45MDTZFB5GDAVCNFSM6AAAAABHOQYJTOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBSGE4TONJUHE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
This open bug report was migrated from #393 |
Beta Was this translation helpful? Give feedback.
-
|
@MeenaAmz any ETA/status on this bug being fixed? This is such a ridiculous regression from MWS to SPAPI. |
Beta Was this translation helpful? Give feedback.
-
|
The documentation is currently at https://developer-docs.amazon.com/sp-api/docs/reports-api-v2021-06-30-reference#processingstatuses and still contains this bug where 2 completely different meanings are used for 1 return code. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
MWS had a
DONE_NO_DATAstate. I had sort of assumed SPAPI would still haveDONE_NO_DATA, but searching the documentation I couldn't find it.But then I found this strange documentation on the
CANCELLEDstate, from https://github.com/amzn/selling-partner-api-docs/blob/main/references/reports-api/reports_2020-09-04.md :It sounds like it's now impossible to differentiate a truly cancelled report, from a successful report that just happens to return 0 rows of data. If so, that's a bizarre and horrible regression from MWS to SPAPI. But if so, it should really be very explicitly documented that
DONE_NO_DATAhas been removed, and it's now impossible to differentiate a cancelled report from done with no data.I sure hope this wasn't intentional though, and the SPAPI can be fixed to restore the
DONE_NO_DATAstatus.Beta Was this translation helpful? Give feedback.
All reactions