Report Cancellation Reasons are not documented correctly

[kpconnell]

If you need help troubleshooting a problem with Selling Partner APIs, please open a support case. Issues are for reporting documentation bugs and enhancements only.

Describe the bug
The documentation only describes two reasons a report has been cancelled, and that is not correct

URL of the content on GitHub
https://github.com/amzn/selling-partner-api-docs/blob/main/references/reports-api/reports_2021-06-30.md

Description of what the documentation currently says
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.

Description of what the documentation should say
It should state the other reasons why a report has been cancelled. At least one of those reasons is you are requesting it too frequently.

Screenshots

Additional context

[ShivikaK]

Hello @kpconnell

Thank you for raising this issue.

Can you provide us with a report ID or a timestamp to review the cancelled reports on our end?

Thanks,
Shivika Khare
Selling Partner API Developer Support

[moltar]

100% this!

This cancellation and fatal business is so poorly documented it's nearly impossible to get data reliably.

We have been banging our head for months!

It's like doing black box testing or pen testing.

Nothing works as advertised!

[kpconnell]

@ShivikaK ShivikaK

amazon.com marketplace, for report GET_AMAZON_FULFILLED_SHIPMENTS_DATA

Successful call, with data : request id 112077018882, date range 2021-08-10 to 2021-09-10 2421 rows
Cancelled Call, same date range: 112078018882

The other reason I have gleaned that cancel happens is if you request too much data. I believe the documentation should state the three (and possibly more) reasons a report can be cancelled. (And FWIW, the status enum should be expanded to include "CANCELLED_THROTTLE", "CANCELLED_NO_DATA" and "CANCELLED_TOO_MUCH_DATA" or something like that.

[moltar]

Ugh had no idea about "too much data" state.

As a developer, how one can even figure this out? How are we expected to load the data reliably?

[stefnats]

+1

I cannot get data reliably, because i don't know if a report was cancelled because of a failure or if there is no data (in MWS there was _DONE_NO_DATA_ which was useful for this exact case)

[jakeleventhal]

yeah there really needs to be a way to tell when a report has no data or when a report fails because too much data is requested. I would say that the reports API is unusable for this reason. how is a developer supposed to know if the data has already been processed or if there is no data at all? and if there is an error because too much data, it should either fatal or have its own report status enumeration

[kpconnell]

@stefnats @jakeleventhal MWS reports behave exactly in the same way - DONE_NO_DATA is not reliable in MWS.

[samborambo305]

This needs to be addressed as soon as possible. How can I build an application if I cannot reliably discern the cause of a cancelation, how can I build a reliable application. We got around this on MWS by just re-requesting the same report until we had good data on a query we knew should yield a good result. Please fix this asap.

[stefnats]

Is there any progress or statement on this @ShivikaK ?

[jimmy-ross-xapix]

+1

we have been struggling for months due to "fatal" responses with no reason thats properly documented

[kpconnell]

Update: FATAL can also mean "this marketplace doesn't process those kinds of transactions" - e.g. GET_FBA_FULFILLMENT_CUSTOMER_RETURNS_DATA in A2ZV50J4W1RKNI marketplace.

[samborambo305]

@ShivikaK Can we get an update on this? This is of highest priority for our migration from MWS to SP.

[kpconnell]

@jevoniuk @mentiaa @salric @rickdeee

bump and spamming you all on this one, as we have onboarded more and more storefronts to the new Reports API there is a lot of strange behavior related to report statuses (Both cancelled and fatal) across many different reports. please advise. this is not an "open a case" situation, its a "Get the documentation right or fix the underlying systemic issues on the platform"

[kpconnell]

Fatal Report ID's against NA endpoint and Amazon.com marketplace id
GET_FBA_FULFILLMENT_CUSTOMER_RETURNS_DATA 684223019124
GET_FBA_MYI_UNSUPPRESSED_INVENTORY_DATA 684634019126
GET_FBA_MYI_UNSUPPRESSED_INVENTORY_DATA 684643019126
GET_AFN_INVENTORY_DATA 684644019126
GET_FBA_MYI_UNSUPPRESSED_INVENTORY_DATA 1371711019131
GET_FBA_MYI_UNSUPPRESSED_INVENTORY_DATA 1371879019131
GET_FBA_ESTIMATED_FBA_FEES_TXT_DATA 1371884019131
GET_FBA_FULFILLMENT_LONGTERM_STORAGE_FEE_CHARGES_DATA 1371885019131
GET_FBA_FULFILLMENT_INVENTORY_HEALTH_DATA 1371888019131
GET_FBA_MYI_UNSUPPRESSED_INVENTORY_DATA 694065019131
GET_AFN_INVENTORY_DATA 694066019131
GET_FBA_MYI_UNSUPPRESSED_INVENTORY_DATA 536260019131
GET_FBA_ESTIMATED_FBA_FEES_TXT_DATA 536291019131
GET_FBA_FULFILLMENT_INVENTORY_HEALTH_DATA 536295019131
GET_FBA_MYI_UNSUPPRESSED_INVENTORY_DATA 196234019126
GET_AFN_INVENTORY_DATA 196235019126
GET_FBA_ESTIMATED_FBA_FEES_TXT_DATA 197120019131
GET_FBA_FULFILLMENT_LONGTERM_STORAGE_FEE_CHARGES_DATA 197121019131
GET_FBA_FULFILLMENT_INVENTORY_HEALTH_DATA 197124019131
GET_FBA_MYI_UNSUPPRESSED_INVENTORY_DATA 378658019126
GET_FBA_MYI_UNSUPPRESSED_INVENTORY_DATA 267611019131
GET_FBA_FULFILLMENT_LONGTERM_STORAGE_FEE_CHARGES_DATA 267616019131
GET_FBA_ESTIMATED_FBA_FEES_TXT_DATA 267636019131
GET_FBA_FULFILLMENT_INVENTORY_HEALTH_DATA 267640019131
GET_FBA_FULFILLMENT_INVENTORY_RECEIPTS_DATA 267645019131
GET_FBA_MYI_UNSUPPRESSED_INVENTORY_DATA 236979019131
GET_FBA_MYI_UNSUPPRESSED_INVENTORY_DATA 188374019131
GET_FBA_MYI_UNSUPPRESSED_INVENTORY_DATA 571576019126
GET_FBA_MYI_UNSUPPRESSED_INVENTORY_DATA 572429019131
GET_FBA_FULFILLMENT_LONGTERM_STORAGE_FEE_CHARGES_DATA 572444019131
GET_FBA_ESTIMATED_FBA_FEES_TXT_DATA 572447019131
GET_FBA_FULFILLMENT_INVENTORY_RECEIPTS_DATA 572449019131
GET_FBA_FULFILLMENT_INVENTORY_HEALTH_DATA 572450019131
GET_FBA_MYI_UNSUPPRESSED_INVENTORY_DATA 401910019126
GET_FBA_MYI_UNSUPPRESSED_INVENTORY_DATA 240666019126
GET_FBA_MYI_UNSUPPRESSED_INVENTORY_DATA 399656019126
GET_FBA_MYI_UNSUPPRESSED_INVENTORY_DATA 400684019131
GET_FBA_MYI_UNSUPPRESSED_INVENTORY_DATA 115619019126

[kpconnell]

Cancelled Report Request Id's, Amazon.Com marketplace (NA Endpoint)

GET_FBA_FULFILLMENT_INVENTORY_RECEIPTS_DATA | 684637019126
GET_FBA_FULFILLMENT_INVENTORY_RECEIPTS_DATA | 1368838019126
GET_FBA_FULFILLMENT_CUSTOMER_RETURNS_DATA | 144823019124
GET_FBA_FULFILLMENT_CUSTOMER_RETURNS_DATA | 144851019124
GET_FBA_FULFILLMENT_CUSTOMER_RETURNS_DATA | 144872019125
GET_FBA_FULFILLMENT_INVENTORY_RECEIPTS_DATA | 693032019126
GET_FBA_FULFILLMENT_INVENTORY_RECEIPTS_DATA | 694068019131
GET_FBA_FULFILLMENT_LONGTERM_STORAGE_FEE_CHARGES_DATA | 79906019131
GET_FBA_FULFILLMENT_REMOVAL_SHIPMENT_DETAIL_DATA | 79908019131
GET_FBA_FULFILLMENT_INVENTORY_RECEIPTS_DATA | 535187019126
GET_FBA_FULFILLMENT_INVENTORY_RECEIPTS_DATA | 536267019131
GET_FBA_FULFILLMENT_LONGTERM_STORAGE_FEE_CHARGES_DATA | 536292019131
GET_FBA_FULFILLMENT_INVENTORY_RECEIPTS_DATA | 196237019126
GET_FBA_FULFILLMENT_INVENTORY_RECEIPTS_DATA | 197109019131
GET_FBA_FULFILLMENT_INVENTORY_RECEIPTS_DATA | 378715019126
GET_FBA_FULFILLMENT_INVENTORY_RECEIPTS_DATA | 381468019131
GET_FBA_FULFILLMENT_LONGTERM_STORAGE_FEE_CHARGES_DATA | 267637019131
GET_FBA_FULFILLMENT_INVENTORY_RECEIPTS_DATA | 236986019131
GET_FBA_FULFILLMENT_LONGTERM_STORAGE_FEE_CHARGES_DATA | 158793019131
GET_FBA_FULFILLMENT_LONGTERM_STORAGE_FEE_CHARGES_DATA | 128578019131
GET_FBA_FULFILLMENT_INVENTORY_RECEIPTS_DATA | 128583019131
GET_FBA_FULFILLMENT_INVENTORY_RECEIPTS_DATA | 571563019126
GET_FBA_FULFILLMENT_INVENTORY_RECEIPTS_DATA | 572432019131
GET_FBA_FULFILLMENT_INVENTORY_RECEIPTS_DATA | 401913019126
GET_FBA_FULFILLMENT_INVENTORY_RECEIPTS_DATA | 240669019126
GET_FBA_FULFILLMENT_INVENTORY_RECEIPTS_DATA | 399601019125
GET_FBA_FULFILLMENT_INVENTORY_RECEIPTS_DATA | 399659019126
GET_FBA_FULFILLMENT_INVENTORY_RECEIPTS_DATA | 400691019131
GET_FBA_FULFILLMENT_INVENTORY_RECEIPTS_DATA | 412713019126

[stefnats]

I agree completely on this one.
We have to guess and build a retry logic based on the report type and the cancel/fatal status.
Making a clearer error description would benefit all devs.

[samborambo305]

You want us to spend our time migrating to a new API but you can't even address this issue which should be an easy fix on your end.

[pascal-m19]

+1
We absolutely need a way to be able to differentiate at least empty reports (with no data) from any other reports that end up having the same CANCELLED status.

Client application should consider empty reports as successful reports while most of the time other "CANCELLED" reports may need to be retried.

[github-actions]

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.

[jakeleventhal]

tia is still an issue on the latest version

[cgaugel]

GET_FBA_STORAGE_FEE_CHARGES_DATA also CANCELLED everytime

[titansoftime]

GET_FLAT_FILE_ALL_ORDERS_DATA_BY_ORDER_DATE_GENERAL GET_FLAT_FILE_RETURNS_DATA_BY_RETURN_DATE is also CANCELLED every time.

[kpconnell]

@titansoftime We use this one all the time - if you're getting cancelled, its going to be because you are requesting it too frequently, or no data. Hence the original ticket...

GET_FLAT_FILE_ALL_ORDERS_DATA_BY_ORDER_DATE_GENERAL is also CANCELLED every time.

[titansoftime]

Oh my, I copied the wrong report. Yes that one works fine every time. It is GET_FLAT_FILE_RETURNS_DATA_BY_RETURN_DATE that is failing 100%.

Sorry about that =[

[jakeleventhal]

@titansoftime I noticed i got this error when requesting a date range in excess of whats allowed. i dont recall 100% if it was this report specifically. but try fetching this report for the last 7 days or something and see if you still get that

[ivanzamoraarias]

Hi ! I am having the same issue here with GET_FBA_STORAGE_FEE_CHARGES_DATA .
I have a request from 2023-07-01 to 2023-07-31 and it is getting canceled every time.
Why is this happening if the other months it works fine ? should we wait more time for the data to be published ?

[titansoftime]

@ivanzamoraarias It seems that if there is no data to be returned for reports, the requests come back as "CANCELLED" from Amazon. Not a very clear error message imo.

[MaksymV1999]

Bump +1

[MaksymV1999]

PLEASE MAKE SOME CHANGES TO THE DOCUMENTATION.
CNCELLED status is clearly indicates that report were canceled for some reason, but we SHOULD NO RECEIVE a CANCELLED status WHEN REPORT IS EMPTY!!

This is very unobvious behavior also this moment is very poorly documented so we've spend a lot of time just to figure out that we also can receive CANCELLED when report just have no data..

[chastain1337]

I am also intermittently experiencing this issue. Frequently getting FATAL on a report with no documentId to explain why. I have tweaked the date range, waiting long stretches in between calls, and more with no consistent results. This is unusable.

[ahmetsabri]

GET_FLAT_FILE_RETURNS_DATA_BY_RETURN_DATE always FATAL if we don't pass start date and end date

[github-actions]

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.

[moltar]

It's an issue.

[ubaidullah-qbatch]

This is still an active issue in (April-2024) with SP-API. GET_FLAT_FILE_RETURNS_DATA_BY_RETURN_DATE report is still getting cancelled always.

[johnkw]

All or almost all of this bug is a duplicate of the earlier bug #393.

[shreeharsh-a]

Please reach out to developer support so that we can better help you with issues related to SP API.

Note: SP API or docs related issues / troubleshooting support is managed by a different team. We can help if the issue is related to the content published on this repo.