Repository navigation
release: 2.1.1 - #117
release: 2.1.1#117
Conversation
Re-executing a query with other params aborted the `abort` stored on its old hash, and a hash is shared by every query with the same params: the request of another query could be the one aborted, and that query ended idle with no data and no error. Each action now keeps a lease on the request it waits on and releases only its own. A read() that joins a request in flight takes a lease too, so a shared request is aborted only when no query waits on it any more; a clean up still never aborts a request. In the read() join: - the query joins the hash before awaiting, so it shows the request as loading, and no longer registers again once the request ends: that re-registration enabled again a query cleaned up meanwhile, sent a query shared by name back to the old params, and cleared the handles of a newer request on the hash, which could then stay loading for ever; - with a persistence shorter than a request, a query releases its older request on the same hash and waits on the newer one with its own lease. An aborted request sets its hash back to idle only while the hash still holds that request, identified by its response promise: the hashes of submit() and remove() now hold it while loading too. Fixes #111 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
submit() set the key of a single payload on the params object it got, the caller's own one on the execution started by the call and on the ones of autoExecute. A later execute() with the payload of another item kept the first key and updated the first item, and with reactive params and autoExecute the write triggered the watcher again, so the same update was sent twice. execute() now works on a copy of the params. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ted one Follow-up to the CodeRabbit review of #116. A repository may hand back the request already in flight for the same key, with the same response promise. A read() that asked for it again created a second pending request for that promise and released its older lease before taking the new one, so it could abort the request it was about to wait on. The leases of a response promise are now counted on one pending request, and a query takes its new lease before it releases the older ones. A read() with the params of a request that was just aborted, before it settled, joined it and resolved as aborted. It now sends a new request instead, without the repository key: RepositoryHttp deduplicates reads by key and would hand back the aborting request until it settles. A pending request is marked aborted only when it had an `abort` to call. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
fix: abort only the query's own request on re-execution, and stop submit() from mutating params
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|



Release 2.1.1
Fixes #111 and a
submit()params bug (#116).Changed
read()that moves to params already cached or already loading now aborts its own previous request too, as it does when it sends a new one (unless another query still waits on that request).submit()orremove()in flight now holds thepromiseof its request, as the one of aread()does.Fix
idlewith no data and no error (Re-executing a query can abort a request that belongs to another query #111).read()that joins a request in flight keeps it running when the query that sent it moves on, and gets its data. While it waits it shows the request as loading, and it no longer switches back to old params, or enables again a query cleaned up meanwhile.read()calls sharing anamefollow the params of the last execution.persistenceshorter than a request, or a repository that hands back the request in flight) no longer abort a request that a query still waits on, and no longer leave the hashloadingfor ever.read()with the params of a request that was just aborted, before that request ends, sends a new request instead of resolving as aborted.idlethe result of another query with the same params.submit()no longer writes the payload key into the caller'sparams. A laterexecute()with the payload of another item updated the first one, and with reactiveparamsandautoExecutethe same update was sent twice.Notes
Patch bump: bug fixes only, no API change (the emitted
index.d.tsis identical to 2.1.0). The two "Changed" items affect a request that no query waits on any more, and the hash state.Dependencies unchanged:
typescript7 is still held back, andvitest5.0.3 was under the one-day minimum release age when #116 was prepared.After the merge, pushing the
v2.1.1tag creates the GitHub release, which publishes to npm. #111 closes when this lands onmain.See
CHANGELOG.mdfor the full[2.1.1]entry.🤖 Generated with Claude Code