Bug: Inconsistent error handling for data source failures

[leogdion]

Problem

Data source failures are handled inconsistently in DataSourcePipeline:

• ipsw.me (line 228): Failures throw and halt entire sync
• AppleDB (line 269): Failures continue silently with warning

This creates unpredictable behavior and makes it unclear which sources are required vs optional.

Proposed Solution

1. Document strategy: Define required vs optional data sources
2. Consistent handling: Either all optional (best effort) or mark some as required
3. Partial success reporting: Return information about which sources succeeded/failed

Example:

struct FetchResult {
    let images: [RestoreImageRecord]
    let xcodeVersions: [XcodeVersionRecord]
    let failures: [DataSourceFailure]
}

4. Validate dependencies: Ensure RecordInfo.isError property exists in MistKit (BushelCloudKitService.swift:106)

Impact

• Reliability: Predictable behavior for source failures
• Debugging: Clear indication of which sources failed
• User Experience: Better error messages

Files Affected

• Examples/Bushel/Sources/BushelImages/DataSources/DataSourcePipeline.swift:228, 269
• Examples/Bushel/Sources/BushelImages/CloudKit/BushelCloudKitService.swift:106

References

• PR update from writing blog post and examples MistKit#129 Review: update from writing blog post and examples MistKit#129 (comment)
• Section: Error Handling Gaps
• Related: Add comprehensive test suite for Bushel demo MistKit#136

[leogdion]

Status: ⚠️ INTENTIONAL DESIGN - Documentation Clarification Recommended

The mixed error handling approach in DataSourcePipeline is intentional: critical sources throw errors while optional sources continue gracefully. However, this philosophy is not documented.

Current State

File: Examples/BushelCloud/Sources/BushelCloudKit/DataSources/DataSourcePipeline+Fetchers.swift

Error Handling Strategy:

Critical Sources (throw errors):

• ipsw.me (lines 70-73): Throws after logging ✅
• MESU (lines 93-96): Throws after logging ✅
• Mr. Macintosh (lines 140-143): Throws after logging ✅
• TheAppleWiki (lines 163-166): Throws after logging ✅

Optional Sources (continue gracefully):

• AppleDB (lines 116-120): Catches error and returns empty array ✅
• VirtualBuddy (lines 187-191): Catches error and returns original images ✅

Analysis

This is an intentional design choice, not a bug:

• Critical sources are required for complete data
• Optional sources provide supplementary information
• Failures in optional sources don't prevent the sync operation
• The code works as intended

What Remains (Optional Documentation Enhancement)

To make the error handling strategy explicit, add documentation to DataSourcePipeline+Fetchers.swift:

/// Fetches restore images from various data sources.
///
/// ## Error Handling Strategy
///
/// Data sources are classified as either critical or optional:
///
/// **Critical Sources** (failures throw):
/// - ipsw.me: Primary source for restore images
/// - MESU: Apple's official update catalog
/// - Mr. Macintosh: Restore image metadata
/// - TheAppleWiki: Additional restore image data
///
/// **Optional Sources** (failures continue):
/// - AppleDB: Supplementary device information
/// - VirtualBuddy: Virtualization-specific metadata
///
/// Critical source failures halt the pipeline to ensure data completeness.
/// Optional source failures are logged but don't prevent sync operations.
extension DataSourcePipeline {
    // ...
}

Recommendation

The error handling works as intended and follows a logical strategy. Adding documentation would make the design philosophy explicit for future maintainers. This enhancement is optional - the issue can be closed if documentation is not desired.