Bug: Incorrect retriability classification in CelestraError

[leogdion]

Problem

CelestraError.swift has incorrect retriability classifications:

• invalidResponse and underlyingError may be incorrectly classified as retriable or non-retriable
• May cause unnecessary retries or miss retriable errors

Proposed Solution

Review and correct retriability logic for each error case:

var isRetriable: Bool {
    switch self {
    case .networkError, .timeout:
        return true  // Network issues are retriable
    case .invalidResponse:
        return false  // Malformed responses won't fix on retry
    case .underlyingError(let error):
        // Check underlying error type
        if let urlError = error as? URLError {
            return urlError.code == .timedOut || 
                   urlError.code == .networkConnectionLost
        }
        return false
    case .rateLimited:
        return true  // Can retry after backoff
    }
}

Impact

• Reliability: Correct retry behavior
• Performance: Avoid wasteful retries
• User Experience: Faster failure for non-retriable errors

Files Affected

• Examples/Celestra/Sources/Celestra/Services/CelestraError.swift

References

• PR update from writing blog post and examples #129 CodeRabbit Review: update from writing blog post and examples #129 (CelestraError.swift)
• Related: Add comprehensive test suite for Bushel demo #136

[leogdion]

Status: ✅ FIXED

This issue has been resolved. CelestraError now has comprehensive and correct retriability classification logic.

Evidence

File: Examples/CelestraCloud/Sources/CelestraCloudKit/Services/CelestraError.swift

Implementation Details:

1. isRetriable property (lines 68-78):

   • CloudKit errors delegated to specialized handler ✅
   • Network errors (rssFetchFailed, networkUnavailable) marked as retriable ✅
   • Non-retriable errors properly classified: quotaExceeded, invalidFeedData, batchOperationFailed, permissionDenied, recordNotFound, cloudKitOperationFailed, invalidRecordName ✅

2. isCloudKitErrorRetriable() (lines 130-148):

   • HTTP 5xx errors: retriable ✅
   • HTTP 429 (rate limit): retriable ✅
   • HTTP 4xx (except 429): not retriable ✅
   • Network errors: retriable ✅
   • Decoding errors: not retriable ✅

Benefits

• Correct retry behavior prevents wasteful retries
• Users get faster failures for non-retriable errors
• Proper handling of transient vs permanent failures

Recommendation

This issue can be closed as the retriability logic is comprehensive and correct.

[leogdion]

Closing as fixed. Retriability classification is comprehensive and correct.