SourceRequest: Lazily provide local file path?

Description

Right now, adapters have two choices when providing a Source object (in stack trace, etc)

• Provide a local file name that the client can natively open by itself, with Path
• Provide a SourceReference that the client can then query lazily later

The problem with these 2 choices is that clients treat SourceReference-based files as ephemeral for the current session (aka "scripts"), and breakpoints etc will be discarded by the client when it stops/restarts a debugging session.

The usecase I am trying to address is SourceLink (or equivalent) methods of acquiring files that are permanent and immutable. If the client has something like the Parallel stacks view opened, it would be impractical to go do a billion SourceLink requests just to be able to give valid local paths, and so I use the SourceReference approach. However, the current shape of the SourceResponse is that it gives the raw content of the file, and the client will discard any user state it had for that file on restart.

In these usecases where the lazy files are immutable and permanent, I would like to be able to cache them to some adapter-defined arbitrary location and tell the client that the file now has a path as part of a SourceResponse.

Question / feature

This would technically be implementable today by clients if the adapter sends a SourceLoadedEvent alongside the SourceResponse, but this sounds hacky, and AFAIK this really does not fit the interpretation of SourceLoadedEvent of clients (or at least that of VS).

• Could SourceResponse be extended to include a filepath if one can be known lazily?

or another idea

• Could the protocol specify that if a Source object has both Path and SourceReference, that the client must not attempt to open the physical file prior to sending a SourceRequest? That would give the opportunity to the adapter to fill the file. Of course with some new flag somewhere at the capabilities level or something, to opt into this new mode.

Start by reviewing the protocol definitions and semantics for SourceResponse, SourceReference, Source.Path, and SourceLoadedEvent. Compare the two proposed behaviors in the issue and determine which can be specified without breaking existing clients. Done means the protocol change and its client capability or compatibility rules are agreed and documented.