Description

assetsStore.updateAssetTags dispatches removeAssetTags and addAssetTags as two separate network calls, then rolls the in-memory cache back if either rejects. When the remove succeeds server-side but the subsequent add fails, the rollback restores the cache to the original tags — but the server has already dropped the removed tag. The cache and backend diverge until the next refetch.

This is a strict subset of the optimistic-update gap; #8179 covered adding rollback logic in general, which has now landed (see #11672). The remaining gap is the partial-success case where rollback itself isn't sufficient because the server is no longer in the original state.

Repro

In src/stores/assetsStore.ts, updateAssetTags:

1. User changes an asset's category from loras → checkpoints.
2. removeAssetTags(['loras']) succeeds (HTTP 200).
3. addAssetTags(['checkpoints']) fails (HTTP 5xx / network drop).
4. Cache rolls back to ['models', 'loras']. Server now has ['models'].
5. Until the next refetch, the UI shows a tag the asset no longer has on the server.

Documented in the existing test rolls back the cache when removeAssetTags succeeds but addAssetTags rejects (src/stores/assetsStore.test.ts).

Possible fixes

• Compensating action: on add-failure after a successful remove, re-issue addAssetTags with the originally-removed tags to restore the server state (best-effort).
• Force a refetch on partial failure so the cache reconciles with whatever the server actually has.
• Move to a single transactional endpoint that accepts the full new tag set and applies the diff atomically server-side.

Context

• PR landing the rollback work: test: add unit tests for assetsStore #11672
• Earlier general rollback issue: Add rollback logic for optimistic cache updates in assetsStore #8179
• Surfaced in review: test: add unit tests for assetsStore #11672 (comment)

┆Issue is synchronized with this Notion page by Unito