Transactions retry even when offline
I hope there no rate limiting for this channel
Currently, TransactionExecutor attempts to execute transactions even when navigator.onLine === false.
This causes:
- A potential significant amount of unnecessary network calls
- Continuous error throwing until the 10-retry limit is hit
- Potential loss of transactions if the offline session is too long
Proposed Solution
Enrich the OfflineConfig interface with an onlineDetector option and Check online status before executing transactions.
This allows the users to preserve the current behaviour while offering a better DX.
- Avoids retries on network errors when offline
- Keeps transactions in scheduler for auto-execution when notifyOnline() is called
- Saves retries for actual failures, not connectivity issues
- Consistent with existing pattern (storage, leaderElection are injectable)
- Flexible: users can provide custom detection logic (ping endpoint, etc.)
- Non-breaking: default uses DefaultOnlineDetector, pass null for old behavior
Currently, TransactionExecutor attempts to execute transactions even when navigator.onLine === false.
This causes:
- A potential significant amount of unnecessary network calls
- Continuous error throwing until the 10-retry limit is hit
- Potential loss of transactions if the offline session is too long
Proposed Solution
Enrich the OfflineConfig interface with an onlineDetector option and Check online status before executing transactions.
This allows the users to preserve the current behaviour while offering a better DX.
- Avoids retries on network errors when offline
- Keeps transactions in scheduler for auto-execution when notifyOnline() is called
- Saves retries for actual failures, not connectivity issues
- Consistent with existing pattern (storage, leaderElection are injectable)
- Flexible: users can provide custom detection logic (ping endpoint, etc.)
- Non-breaking: default uses DefaultOnlineDetector, pass null for old behavior
