fix: breakpoints not persisting in ephemeral files after reload

[connor4312]

Fixes #274

This became more interesting than expected. There were two problems.
Fixing either of them resolves the linked issue, but let's
take care of them both.

1. It seems like (some?) files imported in the extension host include
   the Node.js module prefix in their hashed content. Maybe this is an
   Electron thing; I haven't seen it happen before. This was causing
   us to treat those sources as runtime-only and not trust the disk.

2. It looks like VS Code will preserve file source references between
   runs. For us, the source references are pretty ephemeral, incremented
   globally for the lifetime of the debug adapter. So in fact if you
   restart the debug session, you're guarenteed to never get any
   overlapping source references from the previous session.

   I'm not sure whether this should change. We could reset the increment
   between sessions so that scripts might get the same references, but
   it's just a matter of load order, and if a small change caused a
   script to be inserted early on then every reference will be different.
   Alternatively we could form the source reference off a hash of some
   metadata about the file. If we got a collision we'd need to increment
   but it might be a nice way to make things usually work.

   For now, in setBreakpoints I have just made a change to remove the
   source reference if we see it coming in for a source we don't have
   but which has a path we can fall back to.

[roblourens]

You could also take advantage of the adapterData property on Dap.Source to store something like the path+hash that would let you match a Source from a previous session with the same one with different sourceReference in the current session.

[connor4312]

Good idea. I have it kind of working, but it looks like VS Code gets somewhat confused about breakpoints moving between sources references. In this scenario:

• I set a breakpoint in a file that doesn't exist on disk.
• I restart the session. I hit the breakpoint, but my debugger is paused in a 'different' identical file to the one by breakpoint is in. I can switch between the two.

Over DAP, here's what happens:

1. setBreakpoints in the original file

This is okay. The sourceReference points to the old file, but using the url we can find the original one. Note that the path doesn't actually resolve anywhere--if it did resolve to a valid file, the source reference would be 0 per spec.

{
  "source": {
    "name": "bootstrap",
    "path": "/Users/copeet/Github/vscode-pwa/demos/webpack/webpack/bootstrap",
    "sourceReference": 100,
    "adapterData": {
      "url": "file:///Users/copeet/Github/vscode-pwa/demos/webpack/webpack/bootstrap"
    }
  },
  "lines": [
    7
  ],
  "breakpoints": [
    {
      "line": 7
    }
  ],
  "sourceModified": false
}

2. loadedSource for new script

A different source reference this time. That's OK, we'll figure things out.

{
  "reason": "new",
  "source": {
    "name": "bootstrap",
    "path": "/Users/copeet/Github/vscode-pwa/demos/webpack/webpack/bootstrap",
    "sourceReference": 304,
    "adapterData": {
      "url": "file:///Users/copeet/Github/vscode-pwa/demos/webpack/webpack/bootstrap"
    }
  }
}

3. breakpoint event

We update the previously-set breakpoint and tell VS Code it got verified in the new source reference. At this point, if I had the new source reference file open, I would expect that VS Code would move the breakpoint into that file.

{
  "reason": "changed",
  "breakpoint": {
    "id": 9,
    "verified": true,
    "source": {
      "name": "bootstrap",
      "path": "/Users/copeet/Github/vscode-pwa/demos/webpack/webpack/bootstrap",
      "sourceReference": 304,
      "adapterData": {
        "url": "file:///Users/copeet/Github/vscode-pwa/demos/webpack/webpack/bootstrap"
      }
    },
    "line": 8,
    "column": 1
  }
}

4. we pause and VS code gets confused

The stacktrace contains the new source reference, and we open that file. However the breakpoint remains in the old source. Clicking on the breakpoint triggers a sources request for the old source reference.

[roblourens]

This will let you resolve breakpoints from old Dap sourceReferences, but will you still generate a different sourceReference for the same document on the second run? Meaning the user might still end up with two tabs open to the same file?

[roblourens]

What's going on here?

[connor4312]

By default breakpoints set before reload will have a source reference, but it's invalid. If we saw that, we used to return undefined, this change falls back to looking at the path/adapter dat.

[roblourens]

I think I misread it, it might be more clear to return byRef instead of calling get a second time.

[connor4312]

but will you still generate a different sourceReference for the same document on the second run? Meaning the user might still end up with two tabs open to the same file?

Yea, this is possible, and quite frequent with the issue I mentioned... We could try to keep a persistent map around. Or do what I mentioned maybe use the script content as a seed to get the source reference, so that unchanged files will always have the same source reference between runs.

[connor4312]

Actually, even with the same source reference between sessions, VS Code still tries to treat them as separate files. I'll update the issue. I think this is the direction I would prefer to go though, so I'll get it in; it doesn't regress anything and should work when Code's behavior is fixed.