-
Notifications
You must be signed in to change notification settings - Fork 53
Add comprehensive error handling documentation and improve collection auto-restart behavior #285
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
… auto-restart behavior - Add error-handling.md documentation covering all TanStack DB error scenarios - Fix collection operations to automatically restart from cleaned-up state - Update navigation to include Error Handling guide - Document SchemaValidationError, transaction rollbacks, and sync error handling 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
🦋 Changeset detectedLatest commit: 3e7d73f The changes in this PR will be included in the next version bump. This PR includes changesets to release 7 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
@tanstack/db-example-react-todo @tanstack/db
@tanstack/electric-db-collection
@tanstack/query-db-collection
@tanstack/react-db
@tanstack/trailbase-db-collection
@tanstack/vue-db
commit: |
Size Change: -196 B (-0.51%) Total Size: 38.4 kB
ℹ️ View Unchanged
|
Size Change: 0 B Total Size: 1.05 kB ℹ️ View Unchanged
|
- Remove unused errors export from index.ts - Update collection-errors test to reflect new auto-restart behavior - Collections now automatically restart from cleaned-up state on operations
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ss
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good, the one thing I would consider doing (which could be in a followup) is to make it easer to determine the reason for an error on a mutation. See the other comment.
try { | ||
todoCollection.insert(newTodo) | ||
} catch (error) { | ||
if (error.message.includes("collection is in error state")) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This patten feels a little flaky if the message changes. A check for a prop or error type may be better?
I wander is an error.reason
which is a fixed set of strings 'collection-error-sate' | 'key-conflict' | 'no-insert-handler' | 'validation-error'
?
Or a distinct Error subclass for each type?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah — agree that named errors would be good — easy follow-up for AI to flip through
Summary
Changes
Documentation
docs/error-handling.md
- Comprehensive guide covering:SchemaValidationError
with validation issues and pathsCode Improvements
cleaned-up
state now automatically restart when operations are called, matching the behavior of other collection access patternsTest plan
🤖 Generated with Claude Code