Fix: Handle Root Warnings and Access the Responses from Queries #913
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi.
@p4vel mentioned in #888 there is a bug when accessing the warnings at the root of the response, because of the change mentioned here: https://developer.xero.com/documentation/api/efficient-data-retrieval
However, I don't think their solution is in keeping with how the system currently works, and I think adding it to the list of elements is likely going to lead to some issues with how other users are parsing the data.
As such, I've added it as a private property under the responses (similar to the root error).
I've also added proper handling for the json response, which I don't believe their solution would have worked with.
I've added a small unit test for this and confirmed that it did work.
Given the documentation indicates that this comes up in the query section, I've also added a private property on the query to save the response during the execution of the query, and a public method for accessing it.
This should allow users to access the response and parse any warnings that may have come through, while handling the content of the response as they like (and shouldn't interrupt any current implementations).
While I was doing this I noticed some issues with the inconsistent PHP versioning.
For example: in the Application file the private attributes on lines 32 to 35 (e.g. $lastApiCall) are all typed properties, however typed properties are not supported until PHP 7.4 (which is inconsistent with the composer PHP version of >=5.5.0).
I wasn't aware of whether you would want to update the composer version or remove the conflicts, so I've left them be for now.
If you'd like, I can make another pull request with the requisite change, should you tell me.