[Bug]: vscode-R 3.0.1: code from other project files silently executed in R session via sess
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 12/100
- Tipo de issue
- Error
- Claridad
- Necesita aclaración
- Estado de actividad
- Activo
- Stack tecnológico
- r, typescript
- Área
- developer-experience
Línea de trabajo
Start by checking whether the foreign code comes from the session watcher: toggle the r.sessionWatcher setting and see if the stray assignments stop, then inspect the sess.workspace task callback registered via sess::.runtime_add_task_callback. The issue does not name a file in the extension to change, and the cause is unconfirmed. Done would mean a reproducible trigger is identified and the extension no longer executes code absent from the console or history. Expect the work to involve the R session interaction and the workspace viewer, which needs domain knowledge.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Area
Session watcher or workspace viewer
Bug description
With vscode-R 3.0.1 and its sess session connection, code I did not send is executed in my live R session. Objects defined in other files of the same project silently appear in the global environment, or overwrite objects I just created. On other occasions the whole workspace has been wiped.
The executed code never appears in the console or the R history. The same workflow in R run from Terminal.app, outside VS Code, stays clean.
I run code line by line from a single R script in a single VS Code window. Restarting R, restarting VS Code, rebooting, and using brand-new scripts did not help.
- An object overwritten between two consecutive commands. I fit lm1 and called emmeans() on it immediately. In between, lm1 was replaced by a different model:
> lm1 <- lmer(speakerstance ~ stance + (1 | ResponseId), data = dtl, REML = F)
> stance <- emmeans(lm1, specs = "stance")
Error in emmeans(lm1, specs = "stance") :
No variable named stance in the reference grid
> summary(lm1)
Formula: compelling ~ reasonable + (1 | ResponseId) + (1 | scen)
Data: dtl
Subset: !is.na(reasonable)
The replacement matches a line in an older version of analysis.R in the same project folder, per VS Code's local file history:
lm1 <- lmer(compelling ~ reasonable + (1 | ResponseId) + (1 | scen), data = dtl, REML = F, subset = !is.na(reasonable))
- Objects appearing that I never created. In a fresh session, difficulty and full (both lmerModLmerTest) appeared in the workspace without my running any code that defines them.
- The foreign code was not sent through the terminal. It appears in neither the console nor the R history (savehistory()).
- The foreign model was fit in the live session, not loaded from a file.
> find("lm1")
[1] ".GlobalEnv"
> environment(formula(lm1))
<environment: R_GlobalEnv>
-
No other startup code or hooks could explain it.
• ~/.Rprofile only defines and attaches two ggplot theme functions.
• There is no project .Rprofile, no .RData, and no Rprofile.site.
• The only task callbacks are "1" (from cli::.onLoad) and "sess.workspace" (from sess::.runtime_add_task_callback).
• No MCP or agent packages are loaded. -
It does not reproduce outside VS Code. The same script, packages and data, run line by line in R from Terminal.app, showed only the objects I created. ls() was clean, and emmeans() on lm1 worked as expected.
Steps to reproduce
start an R terminal with sess connected, run a script line by line, and foreign objects eventually appear.
Expected behavior
That the objects I declared remain the ones that I declared.
Environment
| Component | Version |
|---|---|
| R | 4.5.3 (aarch64-apple-darwin20) |
| vscode-R | 3.0.1 (with sess) |
| VS Code | 1.142.0 (Universal) |
| macOS | Tahoe 26.6.2 |
Relevant R package versions
Relevant VS Code settings
"[r]": {
"editor.defaultFormatter": "REditorSupport.r",
},
"r.plot.useHttpgd": true,
"r.workspaceViewer.removeHiddenItems": true,
"r.sessionWatcher": true,
Logs and additional context
No response
- Lenguaje dominante
- TypeScript
- Estrellas
- 1.2k
- Forks
- 151
- Merge medio
- 1 d 8 h
- PR fusionados (30 d)
- 76
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de REditorSupport/vscode-R
-
[Bug]: indentation clash (formatter vs lintr)Posiblemente ocupada @renkun-ken la tomó hoy. Abiertobug
Dificultad 1/5 Menos de una hora Aptitud para principiantes 92/100
REditorSupport/vscode-R#1883 ·
Los mantenedores suelen responder en 1 día
-
[Bug]: `view` button sends explicit `.GlobalEnv` lookup to terminal instead of `View()` onlyAbiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
REditorSupport/vscode-R#1846 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
(feat) Additional Arrow supportPosiblemente ocupada @Fred-Wu la tomó hace 5 días. Abiertoenhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
REditorSupport/vscode-R#1785 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
Explore a standalone, dependency-free R package for the Data Viewer backendPosiblemente ocupada @eitsupi la tomó hace 7 días. Abierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
REditorSupport/vscode-R#1860 · 11 comentarios · 1 reacción · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 12/100
REditorSupport/vscode-R#1859 ·
Los mantenedores suelen responder en 1 día
Todos los issues de REditorSupport/vscode-R
Issues similares
-
fix(cursor): align Grok 4.7 context window to 256k/500k and drop unsupported max effort tierAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
diegosouzapw/OmniRoute#17386 ·
Los mantenedores suelen responder en 1 día
-
ready-for-agent
Dificultad 2/5 1-3 horas Aptitud para principiantes 77/100
Los mantenedores suelen responder en 1 día
-
area/dashboard kind/bug kind/bug-qa QA/dev-automation
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
vybestack/llxprt-code#3917 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
api-parity
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
IBM/carbon-components-ember#1157 ·
Los mantenedores suelen responder en 1 día