Observed behavior
When you perform certain operations such as copying or moving a resource and publishing a channel, to name a few, the modification does not trigger an immediate attempt to sync those changes. This behavior is unlike what occurs during typical operations such as creating, updating, or deleting, where we'll make an immediate (delayed by at least 2 seconds) attempt to sync.
The reason for this is that the modifications to the IndexedDB tables, and the change events created for the move, copy, or publishing operations, are all created with an IGNORED_SOURCE. This means that the creation of the change event is ignored when detecting changes and triggering a sync because of them. The sync polling ends up picking up these change events to send them to the backend, but that represents an unintentional difference in behavior of handling of these change types vs the typical create, update, and delete.
Expected behavior
We have a clear pathway to recognizing there are changes that need syncing and that we make an "immediate" attempt to sync them, regardless of their change type.
User-facing consequences
The syncing of copy or move events does not occur as quickly as other changes, and makes the experience feel slightly delayed, potentially up to 3 seconds longer than other operations.
Additional information
@ozer550's work integrating websockets needs to hook into this pathway to push the changes to the backend
Steps to reproduce the issue
- Let studio sit idle for a moment
- Duplicate a node when a polling sync request occurs
- Observe the copy event is synced after 5 seconds, not 2 seconds which would occur by calling
debouncedSyncChanges
Observed behavior
When you perform certain operations such as copying or moving a resource and publishing a channel, to name a few, the modification does not trigger an immediate attempt to sync those changes. This behavior is unlike what occurs during typical operations such as creating, updating, or deleting, where we'll make an immediate (delayed by at least 2 seconds) attempt to sync.
The reason for this is that the modifications to the IndexedDB tables, and the change events created for the move, copy, or publishing operations, are all created with an
IGNORED_SOURCE. This means that the creation of the change event is ignored when detecting changes and triggering a sync because of them. The sync polling ends up picking up these change events to send them to the backend, but that represents an unintentional difference in behavior of handling of these change types vs the typical create, update, and delete.Expected behavior
We have a clear pathway to recognizing there are changes that need syncing and that we make an "immediate" attempt to sync them, regardless of their change type.
User-facing consequences
The syncing of copy or move events does not occur as quickly as other changes, and makes the experience feel slightly delayed, potentially up to 3 seconds longer than other operations.
Additional information
@ozer550's work integrating websockets needs to hook into this pathway to push the changes to the backend
Steps to reproduce the issue
debouncedSyncChanges