Argument $sellerReturnReasonCode not passed in /app/vendor/jlevers/selling-partner-api/src/Seller/FBAOutboundV20200701/Dto/ReturnItem.php

[lc-excell]

Problem description:

sellerReturnReasonCode argument is required in ReturnItem. It is also labeled as required in Amazon SP API doc, however it is not included in the response.

https://developer-docs.amazon.com/sp-api/docs/fulfillment-outbound-api-v2020-07-01-reference#returnitem

Error:

PHP Fatal error:  Uncaught ArgumentCountError: SellingPartnerApi\Seller\FBAOutboundV20200701\Dto\ReturnItem::__construct(): Argument #4 ($sellerReturnReasonCode) not passed in /app/vendor/jlevers/selling-partner-api/src/Seller/FBAOutboundV20200701/Dto/ReturnItem.php:0
Stack trace:
#0 /app/vendor/highsidelabs/saloon-sdk-generator/src/Traits/Deserializes.php(74): SellingPartnerApi\Seller\FBAOutboundV20200701\Dto\ReturnItem->__construct('AMZN-0000..', '00000', '0000', NULL, 'Processed', Object(DateTime), NULL, 'UND-UNKNOWN', NULL, 'Sellable', 'FAT1')
#1 /app/vendor/highsidelabs/saloon-sdk-generator/src/Traits/Deserializes.php(96): Crescat\SaloonSdkGenerator\BaseDto::deserialize(Array)
#2 /app/vendor/highsidelabs/saloon-sdk-generator/src/Traits/Deserializes.php(109): Crescat\SaloonSdkGenerator\BaseDto::deserializeValue(Array, 'SellingPartnerA...')
#3 /app/vendor/highsidelabs/saloon-sdk-generator/src/Traits/Deserializes.php(66): Crescat\SaloonSdkGenerator\BaseDto::deserializeValue(Array, Array)
#4 /app/vendor/highsidelabs/saloon-sdk-generator/src/Traits/Deserializes.php(96): Crescat\SaloonSdkGenerator\BaseDto::deserialize(Array)

Code

$this->fbaOutbound()->getFulfillmentOrder($this->_sellerFulfillmentOrderID)->dto();

[dpash]

The schema files provided by Amazon use the same request and response type definitions and they have the same required values even though in reality in many cases, they're only required in the requests and missing from responses. I'm not sure what the best solution to this is.

The current solution is to remove the required fields on a case by case basis when we refactor the schema, but this also removes it for the request too. Another option is to just ignore the required list in responses, but the downside here is that we make more values nullable that is required. A third option is to keep a list somewhere of which required fields in requests are not required in responses.

[jlevers]

Option 3 would definitely be best from a developer experience standpoint, but would take some additional work to update and maintain. I think I'm unlikely to get around to implementing that feature anytime soon, so for now I'm going to stick to just removing the fields, but if anyone else wants to set that up, I'm happy to review the PR.