Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

SourceRequest: Lazily provide local file path?

Aperta
  • Qualcosa non va?
#189 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Ambito
backend-api-design, devtools

Direzione di ricerca

Inizia esaminando le definizioni del protocollo e la semantica di SourceResponse, SourceReference, Source.Path e SourceLoadedEvent. Confronta i due comportamenti proposti nell’issue e determina quale può essere specificato senza compromettere i client esistenti. Il lavoro è completato quando la modifica al protocollo e le relative regole sulle capacità o sulla compatibilità dei client sono concordate e documentate.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

*question feature-request

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.
Lingua principale
HTML
Stelle
1.8k
Fork
173
Merge medio
7g 7h
PR unite (30g)
2

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di microsoft/debug-adapter-protocol

Tutte le issue di microsoft/debug-adapter-protocol

Issue simili

Altre issue su Backend & API Design

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.