similar to #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
similar to #554
Describe the bug
pup notebooks getreturns a differentidfor 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 -> updateworkflow 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{*}" } ] } } } ] } } }Observed (no writes between the three GETs):
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 updatecalls, GET responses additionally showed:{"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;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
datadoghq.compup api v1/notebooks/{id}raw passthrough (server-side, cf. [BUG]pup notebooks updatedoubles every backslash in markdown cells on each round trip #554)