-
Notifications
You must be signed in to change notification settings - Fork 106
Open
Description
Background
Currently, error state tracking is inconsistent across collection types:
- query-db-collection: Tracks
lastErroranderrorCountin closure variables, exposing them via utility functions (collection.utils.lastError(),collection.utils.isError(),collection.utils.errorCount()) - electric-db-collection: Has no error tracking at all - errors are thrown or logged but not stored
- Base Collection: Has
status: 'error'state but no associated error information
This creates an inconsistent developer experience where error handling differs depending on which collection type you're using.
Proposal
Make error tracking a first-class concern in the base Collection class, similar to how status is handled today.
API Changes
Add to CollectionLifecycleManager:
public error: Error | null = null
public errorCount: number = 0
public markError(error?: Error): void {
if (error) {
this.error = error
this.errorCount++
}
this.setStatus('error')
}Expose on Collection:
// Direct property access (like status)
collection.error // Error | null
collection.errorCount // number
// Events
collection.on('error', (event) => {
console.log('Error occurred:', event.error)
})Benefits
- Consistency: All collection types have the same error API
- Better DX: Access
collection.errordirectly instead ofcollection.utils.lastError() - Framework integration: React, Angular, Vue adapters can reactively bind to error state
- Debugging: Errors are preserved and inspectable, not just logged
- Retry logic:
errorCountenables exponential backoff strategies
Migration Path
- Add error tracking to base Collection (non-breaking - new properties)
- Update
query-db-collectionto use base error tracking instead of closure variables (internal change) - Update
electric-db-collectionto pass errors tomarkError()instead of just throwing - Deprecate
collection.utils.lastError()in favor ofcollection.error(breaking in next major)
Open Questions
- Should
markError()clear the error on successful recovery, or should we have a separateclearError()method? - Should errors emit events (
collection.on('error', ...)) in addition to status events? - What should happen to
errorCounton recovery - reset to 0 or preserve for analytics? - Should we track error history (last N errors) or just the most recent?
Related
- Fix error propagation from sync clients to collections #671 - Fixed error propagation where errors weren't being set on collections at all
This came out of the discussion in #671 where we realized error tracking should be baked into the core Collection rather than being add-on utilities.
Metadata
Metadata
Assignees
Labels
No labels