Clarification on Retrying VerificationErrors (Temporary vs Permanent Verification Failures)

[LambdaDigamma]

Hey!

First, thanks for your work on the App Store Server Libraries!
While working with the PHP port of the App Store Server Library (hoels/app-store-server-library-php), I noticed an issue/problem related to handling VerificationException errors during the verification of notifications and transactions.

The verification failure VerificationError.VERIFICATION_FAILURE is returned in various error scenarios.
These scenarios include issues such as invalid certificates and transient failures like network-related exceptions. This behavior makes it difficult to determine whether a failure should trigger a retry, especially in background jobs where transient failures should ideally be handled gracefully. For more insights, please see this issue in hoels/app-store-server-library-php.

Upon reviewing the official Swift (and Python) version of this library, I also found no distinction between different failure types. As a result, developers have no clear way of differentiating between recoverable errors (e.g., network timeouts) and permanent failures (e.g., invalid certificates). This can lead to unnecessary retries or missed opportunities to recover from transient issues.

Suggested Improvement:

I believe it would be beneficial to introduce more granular VerificationError cases to help distinguish between transient errors (e.g., network failures) and permanent verification failures. Specifically, differentiating between:

• Failures caused by network issues (e.g., OCSP requests timing out or returning specific HTTP error codes).
• Permanent verification failures due to invalid certificates or data integrity issues.

By doing so, developers would have the flexibility to handle retries more intelligently (e.g., in background jobs) without unnecessary retries or incorrect error handling.

Potential Concerns:

I didn't look at all the App Store Server Library implementations in detail, but I assume this would be a breaking change to differentiate between those cases.
However, this enhancement could be considered for a future major version to improve overall error-handling capabilities.

Next Steps:

First, I'd like to ask whether this was an intentional design choice or if you overlooked the differentiation between permanent and temporary verification failures. As a potential next step, we could consider adding an additional error case or making the function throw (in a similar fashion to PR #39) and distinguishing between verification results and errors that occurred due to networking issues.

I am looking forward to your insights and opinions on that. Thanks for your work!
– Lennart