[BUG] Notebooks: markdown cell `id` is regenerated on every GET
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
- 35/100
Línea de trabajo
Comienza con la reproducción documentada de pup notebooks create y pup api v1/notebooks/{id} --no-agent usando /tmp/nb.json y, a continuación, compara las respuestas GET repetidas. El informe identifica el comportamiento como del lado del servidor y hace referencia a #554, pero no indica ningún archivo del repositorio ni ninguna prueba que cambiar. Se considera terminado cuando los notebooks sin cambios devuelven ids de celda estables y únicos en las solicitudes GET, tanto para markdown como para otros tipos de celda.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
similar to https://github.com/DataDog/pup/issues/554
Describe the bug
pup notebooks get returns a different id for every markdown cell on each call, while graph cells (e.g. timeseries) keep stable ids. The same happens through the raw passthrough (pup api v1/notebooks/{id}), so the ids change in the API response itself, not in pup's client layer. same layering as #554.
This makes markdown cells unaddressable: any get -> modify -> update workflow that relies on cell ids cannot reference a markdown cell across two calls.
To Reproduce
Save as /tmp/nb.json:
{
"data": {
"type": "notebooks",
"attributes": {
"name": "markdown cell id stability test",
"status": "published",
"time": { "live_span": "1h" },
"cells": [
{ "type": "notebook_cells", "attributes": { "definition": { "type": "markdown", "text": "# Section" } } },
{ "type": "notebook_cells", "attributes": { "definition": { "type": "timeseries", "requests": [ { "display_type": "line", "q": "avg:system.cpu.user{*}" } ] } } }
]
}
}
}
pup notebooks create --file /tmp/nb.json # note the returned notebook id
for i in 1 2 3; do
pup api v1/notebooks/$NB_ID --no-agent | jq -c '[.data.attributes.cells[] | {id, type: .attributes.definition.type}]'
done
Observed (no writes between the three GETs):
[{"id":"2l892wv8","type":"markdown"},{"id":"5k2rqfa5","type":"timeseries"}]
[{"id":"fwhey19c","type":"markdown"},{"id":"5k2rqfa5","type":"timeseries"}]
[{"id":"sjguoeel","type":"markdown"},{"id":"5k2rqfa5","type":"timeseries"}]
The markdown cell gets a fresh id on every GET; the timeseries id is stable.
Expected behavior
Cell ids should be stable across GETs of an unchanged notebook, and unique within a single response, for all cell types.
Additional observations (same root symptom, not minimally reproduced)
On a long-lived notebook that had received several notebooks update calls, GET responses additionally showed:
- an empty markdown cell (
{"type":"markdown","text":""}) after every timeseries cell, each with a fresh id per GET; updates whose payload omits these cells do not durably remove them; - the same cell id appearing twice within a single GET response (4 duplicated ids among 12 timeseries cells).
A freshly created notebook does not show either symptom (single, repeated, rapid-succession, id-bearing and id-stripped updates all round-trip cleanly), so these look like a server-side state/merge condition. Reported together because the markdown id instability above makes id-based diagnosis or repair of such a notebook impossible via the API.
Environment
- OS: macOS 26 (aarch64)
- Pup version: 0.65.4 (rust 1.95.0)
- Auth: OAuth2, site
datadoghq.com - Reproduces identically via
pup api v1/notebooks/{id}raw passthrough (server-side, cf. #554)
- Lenguaje dominante
- Rust
- Estrellas
- 1k
- Forks
- 138
- Merge medio
- 17 h
- PR fusionados (30 d)
- 82
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una 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 DataDog/pup
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
logs search/aggregate silently return partial results when time range exceeds storage-tier retentionAbiertoenhancement product:logs usability
Dificultad 4/5 3-5 días Aptitud para principiantes 52/100
DataDog/pup#717 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
authnz enhancement usability
Dificultad 5/5 Más de una semana Aptitud para principiantes 45/100
DataDog/pup#690 · 3 comentarios · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
documentation enhancement
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
DataDog/pup#669 · 2 comentarios · 2 reacciones ·
Los mantenedores suelen responder en 1 día
Todos los issues de DataDog/pup
Issues similares
-
binding:python bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
coollabsio/orbit#72 ·
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
-
bug order-flow studies ui
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
userFRM/egui-charts#2417 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 2 días