This is the merge decorator, add console.log('HERE', new Error().stack); to extHostEditor#setDecorations

HERE Error
    at ExtHostTextEditor.setDecorations (/Users/jrieken/Code/vscode/out/vs/workbench/api/node/file:/Users/jrieken/Code/vscode/src/vs/workbench/api/node/extHostTextEditor.ts:418:23)
    at __dirname.removeDecorations.Object.keys.forEach.decorationKey (/Users/jrieken/Code/vscode/extensions/merge-conflict/src/mergeDecorator.ts:248:12)
    at Array.forEach (native)
    at MergeDectorator.removeDecorations (/Users/jrieken/Code/vscode/extensions/merge-conflict/src/mergeDecorator.ts:241:33)
    at MergeDectorator.<anonymous> (/Users/jrieken/Code/vscode/extensions/merge-conflict/src/mergeDecorator.ts:185:10)
    at Generator.next (<anonymous>)
    at fulfilled (/Users/jrieken/Code/vscode/extensions/merge-conflict/out/mergeDecorator.js:4:58)

It's incredibly hard to read travis logs right now.

@jrieken There is a check if the editor is in window.visibleTextEditors, but that doesn't seem to help. What is the correct way to check if the editor is not disposed?

@jrieken Using console.log('HERE', this._disposed, new Error().stack); shows that this._disposed is still false when passing through extHostEditor#setDecorations. This seems to be a timing issue between extension host and main process.

extHostTextEditor already logs a warning in _runOnProxy() when the editor is disposed at the time setDecorations() is called. If the editor in the extension host is not disposed, but the one in the renderer process is (and the error is logged), the disposal and the setting of decorations were triggered at a similar time in different processes and it seems best to recover from this silently.

I suggest to remove the error. If an error is still desired, I'd suggest to change the warning in extHostTextEditor's _runOnProxy() to an error.

@chrmarti could you please look into this since all other participants are on vacation? Or assign it to august if it is not critical for our relase

I don't see it as critical for the release. It is log entries for operations that should not run and also are not run. This is without further side-effects. @joaomoreno labelled it as important with regard to the noise in the test runs. I'll postpone it to August if there are no objections.

Nice fix, not. The problem is explained here: #30578 (comment)

@jrieken This seems to be a race condition on the API's side. See #30578 (comment) .

This seems to be a race condition on the API's side

That might well be but the "fix" of this picking this one call is a little lame, isn't it? If we understand this problem why don't we tackle it for all other calls like tryRevealRange etc. Why don't we handle this properly in the _runOnProxy with a well known error code? This just looks like a shortcut to me

We wanted to make progress on this "important" issue in your absence without devising a general solution without your input.

I understand that, but I would have just removed the "important" label because this is really just debt