Continue on for comments doesn't work sometimes

[alexr00]

Testing #193104

To repro, follow the steps in the above test.

[alexr00]

@joyceerhl I'm seeing an unexpected URI in the object that I get from the storage service when I try to restore comments:

The two with the long URI authority restore, because that URI matches the URI that of the files "locally" (it's actually GitHub Repositories, but it's the machine I'm trying to restore on).

[alexr00]

On the machine I'm storing the comment from, the URI doesn't have that long authority:

[alexr00]

I'm seeing this URI difference when trying to restore across two actual different machines using VS Code insiders (desktop) on both.

[joyceerhl]

Hm, I cannot repro because comments aren't showing up at all for me in web https://insiders.vscode.dev/github/microsoft/vscode/pull/193812

[alexr00]

@joyceerhl I'm seeing comments show up as expected for that PR. Can you share output from GitHub Pull Request and see if there are any errors in the console?

[joyceerhl]

OK, comments show up properly for that PR now. I'm still running into some issues though:

1. I had to enable comments.experimentalContinueOn first, otherwise no state was getting stored:

   vscode/src/vs/workbench/contrib/comments/common/commentsConfiguration.ts

   Line 12 in d00c196

   experimentalContinueOn: boolean;

2. I see the following comment state getting stored for the above PR, the first entry seems like stale state since it's not coming from the current workspace. Do you have insight into where it comes from?

[
  {
    owner: 'Hide launcher on Run and Debug title bar when debugging-GitHub.vscode-pull-request-github',
    uri: {
      '$mid': 1,
      fsPath: 'c:\\Users\\huer\\Source\\vscode\\src\\vs\\workbench\\contrib\\debug\\browser\\debug.contribution.ts',        
      _sep: 1,
      external: 'file:///c%3A/Users/huer/Source/vscode/src/vs/workbench/contrib/debug/browser/debug.contribution.ts',       
      path: '/c:/Users/huer/Source/vscode/src/vs/workbench/contrib/debug/browser/debug.contribution.ts',
      scheme: 'file'
    },
    range: {
      startLineNumber: 455,
      startColumn: 1,
      endLineNumber: 455,
      endColumn: 1
    },
    body: 'foo'
  },
  {
    owner: 'Hide launcher on Run and Debug title bar when debugging-GitHub.vscode-pull-request-github',
    uri: {
      '$mid': 1,
      fsPath: '\\microsoft\\vscode\\src\\vs\\workbench\\contrib\\debug\\browser\\debug.contribution.ts',
      _sep: 1,
      external: 'vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a22313933383132227d7d/microsoft/vscode/src/vs/workbench/contrib/debug/browser/debug.contribution.ts',
      path: '/microsoft/vscode/src/vs/workbench/contrib/debug/browser/debug.contribution.ts',
      scheme: 'vscode-vfs',
      authority: 'github+7b2276223a312c22726566223a7b2274797065223a332c226964223a22313933383132227d7d'
    },
    range: {
      startLineNumber: 453,
      startColumn: 1,
      endLineNumber: 453,
      endColumn: 1
    },
    body: 'foooo'
  }
]

3. If I set a breakpoint here I don't see it get hit after we call storeAll with the restored value, i.e. the onDidChangeValue event listener that comments registers doesn't fire, so it doesn't update with the restored comments data, will keep investigating why that might be the case

[alexr00]

I had to enable comments.experimentalContinueOn first, otherwise no state was getting stored

This is intentional. During testing, we couldn't get a good test of the feature so I put it behind a hidden setting so that we didn't accumulate a bunch of junk state for 1.83 for users.

I see the following comment state getting stored for the above PR, the first entry seems like stale state since it's not coming from the current workspace. Do you have insight into where it comes from?

I'm not sure what that could be, but the logging I added yesterday should help shed some light on that. If you set the log level of "Window" to "debug", then you should get lines like "Comments: URIs of continue on comments..." for when we store and retrieve comments to and from the storage service.

[alexr00]

@joyceerhl I found that testing across two desktop installs worked extremely reliably. Before, I was testing across desktop and insiders.vscode.dev, and it was unreliable (as described in step 3) so I didn't notice all the bugs that I had. All the bugs I could find I fixed in #195260.

For testing, I'll update the TPI to ask that testers use two desktop installs of VS Code.