Repository navigation
feat: define shared provider failure semantics - #117
Open
NathanMartinez wants to merge 3 commits into
Open
NathanMartinez wants to merge 3 commits into
NathanMartinez wants to merge 3 commits into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary
Add a small backend-independent failure model and shared transport/decoding adapters for media providers.
This is an additive foundation for translating backend-specific failures into a common application vocabulary without changing existing provider or repository APIs.
No existing provider behavior is changed by this PR.
Motivation
Chora currently supports multiple provider implementations, and additional backends can report equivalent failures in very different ways.
For example:
Handling those directly at higher layers couples recovery and UI behavior to each backend's transport details.
This introduces a shared semantic boundary:
backend / transport details -> ProviderFailure -> recovery / presentationProvider-specific adapters remain responsible for deciding what their backend responses mean.
Failure model
ProviderFailurecurrently represents:AuthenticationRejectedAuthenticationRecoveryFailedRateLimited(retryAfter)UnavailableHttpError(status)ProtocolError(code)InvalidResponseMissingContentProviderExceptioncarries only the semantic failure and deliberately does not retain backend causes that could contain sensitive request or credential information.Shared adapters
The PR also adds focused helpers for common boundaries:
UnavailableInvalidResponseRateLimitedHttpErrorRetry-Afternormalization for both delta-seconds and HTTP-date formsThe helpers intentionally do not catch arbitrary exceptions. Cancellation, programming defects, and unrelated failures remain visible rather than being misclassified as provider availability problems.
Scope
This PR only defines the shared contract and adapters.
It does not:
Provider-specific integrations are implemented separately so they can be reviewed independently.
Testing
Added focused tests covering the failure contract, validation rules, transport classification, decoding classification, HTTP status handling, and deterministic
Retry-Afterparsing.The shared semantic layer and its adapters have also been exercised as part of an integrated provider build without changing their public contract.