Skip to content
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

Prevent Watch Stream Reconnection After Explicit Cancellation #918

Open
chacha912 opened this issue Oct 24, 2024 · 0 comments
Open

Prevent Watch Stream Reconnection After Explicit Cancellation #918

chacha912 opened this issue Oct 24, 2024 · 0 comments
Labels
bug 🐞 Something isn't working

Comments

@chacha912
Copy link
Contributor

chacha912 commented Oct 24, 2024

What happened:

The watch stream should not automatically reconnect when it has been explicitly cancelled, such as when:

  • Detaching a document
  • Switching to manual sync mode

In the quill-two-clients.html example, when switching to manual sync mode, the watch stream:

  1. Disconnects (unwatches) as expected
  2. Unexpectedly reconnects automatically
quill-two-clients2.mov

The watch stream reconnection occurs because:

  • cancelWatchStream(abort) triggers a ConnectErrorCode.Canceled error
  • This error is currently marked as retryable, causing automatic reconnection attempts

We need to:

  1. Identify all scenarios that generate ConnectErrorCode.Canceled errors besides explicit abort
  2. Evaluate whether each scenario should be retryable
  3. Differentiate between intentional cancellation and other cancellation scenarios

What you expected to happen:

Once explicitly cancelled (e.g., by switching to manual sync mode), the watch stream should:

  • Remain disconnected
  • Not attempt automatic reconnection

How to reproduce it (as minimally and precisely as possible):

Run quill-two-clients.html

Or Add a test case to verify this behavior

it('Should cancel watch stream when changing to manual sync mode', async function ({
  task,
}) {
  // Test setup with two clients
  const c1 = new yorkie.Client(testRPCAddr);
  const c2 = new yorkie.Client(testRPCAddr);
  await c1.activate();
  await c2.activate();
  
  // Create and attach documents
  const docKey = toDocKey(`${task.name}-${new Date().getTime()}`);
  const d1 = new yorkie.Document<{ version: string }>(docKey);
  const d2 = new yorkie.Document<{ version: string }>(docKey);
  await c1.attach(d1);
  await c2.attach(d2);

  // Set up event collectors
  const syncEventCollector = new EventCollector();
  const presenceEventCollector = new EventCollector();
  
  // Verify initial sync works
  d2.update((root) => {
    root.version = 'v1';
  });
  await syncEventCollector.waitFor(DocEventType.RemoteChange);
  assert.equal(d1.toSortedJSON(), `{"version":"v1"}`);

  // Switch to manual mode and verify stream closes
  await c1.changeSyncMode(d1, SyncMode.Manual);
  await presenceEventCollector.waitFor(DocEventType.Unwatched);
  
  // Verify stream stays closed
  d2.update((root) => {
    root.version = 'v2';
  });
  await new Promise((resolve) => setTimeout(resolve, 1000));
  assert.equal(presenceEventCollector.getLength(), 0);
  assert.equal(d1.toSortedJSON(), `{"version":"v1"}`, 'keeps old value');

  // Verify manual sync still works
  await c1.sync();
  assert.equal(d1.toSortedJSON(), `{"version":"v2"}`, 'manual sync');
});

Anything else we need to know?:

Environment:

  • Operating system:
  • Browser and version:
  • Yorkie version (use yorkie version):
  • Yorkie JS SDK version: v0.5.3
@chacha912 chacha912 added the bug 🐞 Something isn't working label Oct 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug 🐞 Something isn't working
Projects
Status: Backlog
Development

No branches or pull requests

1 participant