Skip to content

Make ExpoSecureStore dynamic dependency loading failure-safe #155

Description

@coderabbitai

Summary

Replace the timeout-and-polling approach for loading expo-secure-store with an awaited cached load promise that resolves to the module or propagates the import failure.

Rationale

waitForExpoSecureStore() stops waiting after 20 retries (about two seconds), even if the dynamic import remains pending or has failed. Subsequent non-null assertions on expoSecureStore can then cause an unhelpful runtime TypeError rather than reliably awaiting the dependency or surfacing the original import error.

Affected area

  • lib/storage/ExpoSecureStore.ts

Required changes

  • Cache and await the dynamic import promise before accessing the Expo Secure Store API.
  • Propagate dependency-load failures predictably with useful error context.
  • Remove reliance on a fixed polling timeout and unsafe non-null assertions for module availability.

Acceptance criteria

  • Storage operations wait for the same in-flight dependency load rather than polling.
  • A failed expo-secure-store import rejects storage operations with the load failure rather than a later property-access TypeError.
  • Focused tests cover delayed successful loading and rejected loading.

Context

Requested by @victoreronmosele as follow-up work from PR #133.

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions