[BUG] Notebooks: markdown cell `id` is regenerated on every GET
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 35/100
Hướng nghiên cứu
Bắt đầu bằng việc tái hiện theo tài liệu với pup notebooks create và pup api v1/notebooks/{id} --no-agent bằng /tmp/nb.json, sau đó so sánh các phản hồi GET lặp lại. Báo cáo xác định hành vi này là ở phía máy chủ và tham chiếu đến #554, nhưng không nêu tệp nào trong repository hoặc test nào cần thay đổi. Được xem là hoàn tất khi các notebook không bị thay đổi trả về các cell id ổn định, duy nhất qua các GET đối với markdown và các loại cell khác.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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)
- Ngôn ngữ chính
- Rust
- Star
- 1k
- Fork
- 138
- Merge trung bình
- 17 giờ
- Pull request đã merge (30 ngày)
- 82
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của DataDog/pup
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
-
logs search/aggregate silently return partial results when time range exceeds storage-tier retentionĐang mởenhancement product:logs usability
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 52/100
DataDog/pup#717 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
authnz enhancement usability
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 45/100
DataDog/pup#690 · 3 bình luận · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
documentation enhancement
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
DataDog/pup#669 · 2 bình luận · 2 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
Issue tương tự
-
enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
-
bug order-flow studies ui
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
userFRM/egui-charts#2417 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 2 ngày
-
In a plain-text message, Font, Font Size, Font Color and Text Highlight Color stay liveCó thể đã có người làm @ragelfundionctrumnar đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
UCS-Care-Group/mailcraft#862 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
smoltcp-rs/smoltcp#1243 ·
Maintainer thường phản hồi trong vòng 1 ngày