Add optional request params to reject truncated responses and error responses.

[jameshilliard]

Adds tracking for truncated responses and the ability for the retry handler to reject truncated and error responses based on request flags.

[jameshilliard]

First of all it seems you forgot to cover the sync client.

Yeah, the sync client code is rather...tricky IMO, trying to get it working there.

The purpose of the clients in the library is to "send requests and return healthy responses with automatic retry" !

IMO this is just allowing the definition of a healthy response to be configured per request.

This PR starts to add an extra layer that changes the definition to "send requests and return expected responses with automatic retry", it might be better to that in a higher level client (which correspond to the discussion about managing a whole device).

I'm not sure the higher level client layer would be where it makes sense to implement retry logic, that layer I'm thinking would be more for providing a register mapping layer AFAIU but the retry logic seems to me that it would need to be handled at a lower level.

[janiversen]

having a short read, is normal (I am sitting with a device right now that does it), f.x. if the app read registers non existent. As a consequence it is something the app should handle !

Many of the error responses, are not dynamic in nature, so adding them to the retry does not work, apart from that the app needs to check the error flag (as pr other discussion, it is a major change which we can think of for 4.0).

So I do not see a lot of value in this PR (apart from the review comments).

[janiversen]

Still working on this one ?

[jameshilliard]

having a short read, is normal (I am sitting with a device right now that does it)

I mean, I made it a flag tied to the specific request because while truncation may be normal for some devices/registers, it may be not normal for others and indicate some other issue.

As a consequence it is something the app should handle !

At the moment I'm using a wrapper that implements an additional layer of retry logic for both truncation and error flags(retries do seem to reliably mitigate the issue at least with the devices I'm working with), but having two retry loops(one in the app one in the library) effectively doing the same thing seems a bit weird.

Many of the error responses, are not dynamic in nature, so adding them to the retry does not work, apart from that the app needs to check the error flag (as pr other discussion, it is a major change which we can think of for 4.0).

Hmm, I'm guessing this is somewhat firmware dependent, I think having a retry on error capability is still seems somewhat useful in case apps want to delegate retries to the library.

Still working on this one ?

Yes, but somewhat prioritizing the transaction and tests cleanup at the moment.

[github-actions[bot]]

This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[github-actions[bot]]

This PR was closed because it has been stalled for 10 days with no activity.