fix(observability): pin one telemetry snapshot per Logs and Trace response
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
- 45/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- go
- Lĩnh vực
- observability-sre
Hướng nghiên cứu
Start by locating the Logs and Trace response entry points and the existing telemetry statement/index, cache-acknowledgement, and contribution reads. Add deterministic tests that publish, compact, or retain telemetry between response stages, then verify one file set across entries, counts, and trace/log sections; also check cancellation cleanup, publisher progress, and the native and race suites.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
The whole-PR review of #272 identified a low-severity, pre-existing response consistency gap outside its five inline findings: https://github.com/labstack/fanout/pull/272#pullrequestreview-5386440469 .
Logs queries entries and histogram separately. Trace queries a candidate, reads its index, and fetches related logs in separate snapshots. A telemetry publication between those operations can make sections of the same response describe different active file sets.
Pin one bounded telemetry snapshot for every statement/index read that contributes to a single Logs or Trace response. Read cache acknowledgements and contributions transactionally under that snapshot; preserve immediately visible uncached files, exact clipped windows, redaction, cancellation and publisher progress. Define transaction/lock ownership once rather than adding retries or snapshot fallbacks.
Acceptance: deterministic tests publish, compact or retain telemetry between response stages and prove entries/counts and trace/log sections describe one file set. Cancellation releases all resources; publishers still progress under the existing reader grace period; the full native and race suites pass.
- Ngôn ngữ chính
- HTML
- Star
- 6
- Fork
- 0
- Merge trung bình
- 2 giờ 25 phút
- Pull request đã merge (30 ngày)
- 25
Chuẩn bị môi trường
- Có Dockerfile hoặc 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 labstack/fanout
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 42/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của labstack/fanout
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
Maintainer thường phản hồi trong vòng 1 ngày
-
bug effort:low model:light plan planner:opus-5-5
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Block Node Improvement
Độ khó 2/5 Nửa ngày Mức phù hợp với người mới 68/100
hiero-ledger/hiero-block-node#3828 ·
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 75/100
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 74/100
open-telemetry/weaver#1827 ·
Maintainer thường phản hồi trong vòng 2 ngày