Skip to content

[Core] 6 - Surface history read failures #466

Description

@KacperKozak

What to build

Carry history and profile read errors through native queries, bridge, stores, and existing error UI. Preserve valid empty results as a distinct successful outcome. Keep implementation simple.

Part 6 of the approved cross-platform persistence reliability plan. Android and iOS remain separate native implementations with shared observable contracts. Local planning document: docs/persistence-reliability-plan.md; this issue is self-contained. Type: AFK.

Likely files

  • modules/vescape-core/ios/telemetry/RideHistoryRepository.swift - production behavior or caller to inspect
  • modules/vescape-core/ios/telemetry/ProfileStatsRepository.swift - production behavior or caller to inspect
  • modules/vescape-core/ios/telemetry/TelemetryRepository.swift - production behavior or caller to inspect
  • modules/vescape-core/android/src/main/java/expo/modules/vescapecore/telemetry/TelemetryDao.kt - production behavior or caller to inspect
  • src/modules/history/store/historyStore.ts - production behavior or caller to inspect
  • src/screens/main/overlays/HistoryDrawer.tsx - production behavior or caller to inspect

Implementation hints

Keep Room on Android and GRDB on iOS. Native owns durable truth; JS renders state and sends intents. Follow bidirectional @parity links and preserve bridge payloads. Custom SQL is allowed for migrations and aggregate updates with real DB tests. Use existing error UI and avoid a generic persistence/recovery framework. Diagnostics transport follows ADR 0031; Sentry handles errors independently of local event persistence. Use bun commands and appropriate scoped verification.

Acceptance criteria

  • Shared fixtures distinguish empty DB from query failure and validate paged ride reads on both platforms.
  • History and profile callers show simple existing error presentation; no stale-data states, caching scheme or retry UI.
  • Existing write aggregates remain the read source; no repair/recalculation side effects on normal reads.
  • Errors report via established native adapter without duplicate JS reporting; successful paging/current-ride behavior remains intact.

Blocked by

Related

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:coreApp shell, storage, lifecycle, infraarea:dbTouches database / persistent storagearea:nativeTouches native side (modules/vesc-ble, Swift/Kotlin)complexity:mediumNeeds care, moderate integration surface. Use sonnet.enhancementNew feature or requestready-for-agentFully specified, ready for an AFK agent

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions