Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

dockerContainerStats subscription returns frozen NetIO/BlockIO values

Đang mở
  • Có gì không ổn?
#2,007 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

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
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
docker, graphql, typescript
Lĩnh vực
api, backend

Hướng nghiên cứu

Start with api/src/unraid-api/graph/resolvers/docker/docker-stats.service.ts and compare its current Docker CLI data source with the Docker socket stats behavior described in the report. Review docker-event.service.spec.ts for the event-stream testing pattern. Done means subscription emissions contain fresh NetIO and BlockIO counters while the GraphQL schema remains unchanged, with tests covering the stream lifecycle.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Environment

Unraid OS Version: 7.3 (Unraid OS)

Are you using a reverse proxy? No — verified by querying the API directly on the server's IP at http://192.168.1.132/graphql.

Pre-submission Checklist

  • I have verified that my Unraid OS is up to date
  • I have tested this issue by accessing my server directly (not through a reverse proxy)
  • This is not an Unraid Connect related issue

Issue Description

The dockerContainerStats GraphQL subscription is documented as emitting live runtime stats for every running Docker container, but the cumulative NetIO and BlockIO string fields stay frozen at the first sample for the entire lifetime of the subscription. CPU% and memory percentages DO update correctly in each emission, so the subscription itself is alive — only the I/O counters are stale.

This breaks any consumer that derives per-second download/upload speeds by taking the delta of netIO between two consecutive emissions (e.g. a third-party dashboard rendering a "live speed" cell per container): the delta is always zero.

Steps to Reproduce

  1. SSH into an Unraid 7.3 server with at least one container that has measurable network traffic (a torrent client actively downloading is ideal).

  2. Subscribe to dockerContainerStats with any GraphQL client that supports graphql-transport-ws. Minimal Node example:

    const ws = new WebSocket('ws://<host>/graphql', 'graphql-transport-ws');
ws.on('open', () => ws.send(JSON.stringify({
  type: 'connection_init',
  payload: { 'x-api-key': API_KEY }  // lowercase header is required
})));
ws.on('message', (raw) => {
  const m = JSON.parse(raw);
  if (m.type === 'connection_ack') ws.send(JSON.stringify({
    id: '1', type: 'subscribe',
    payload: { query: 'subscription { dockerContainerStats { id cpuPercent netIO } }' }
  }));
  if (m.type === 'next') console.log(new Date().toISOString(),
    m.payload.data.dockerContainerStats);
});

  3. Watch the output for ~15 seconds while the target container has active traffic.

Expected Behavior

netIO (and blockIO) should reflect fresh cumulative byte counts on every emission, so the receiving client can compute rates via delta:

14:32:01  netIO=40.1GB / 219.7GB
14:32:02  netIO=40.2GB / 219.7GB   ← Δ ≈ 100MB rx in 1s = 100 MB/s
14:32:03  netIO=40.3GB / 219.7GB

This matches what /containers/<id>/stats?stream=true on the Docker UNIX socket returns (verified directly — see below).

Actual Behavior

netIO is identical across every emission for the full lifetime of the subscription, even while the container has active traffic:

14:32:01  netIO=40.1GB / 219.7GB
14:32:02  netIO=40.1GB / 219.7GB   ← Δ = 0 B
14:32:03  netIO=40.1GB / 219.7GB
...
14:32:13  netIO=40.1GB / 219.7GB   ← still 0 B after 12 emissions

Yet during those same 12 seconds, the Docker daemon's socket shows real growth on the same container:

$ curl -s --unix-socket /var/run/docker.sock \
    http://localhost/containers/qbittorrent/stats?stream=false \
    | jq '.networks.eth0 | {rx_bytes, tx_bytes}'
# t=0
{ "rx_bytes": 40358834652, "tx_bytes": 219765369309 }

$ sleep 3 && curl -s ...   # same query
# t=3s
{ "rx_bytes": 40467550325, "tx_bytes": 219775453453 }

# Δrx ≈ 109 MB over 3 s → 36 MB/s real download rate

And docker stats --no-stream reports the same frozen 40.1GB / 220GB regardless of timing — pointing at the docker CLI itself, not the API.

Additional Context

Root cause appears to be in api/src/unraid-api/graph/resolvers/docker/docker-stats.service.ts, which spawns execa('docker', ['stats', '--format', ..., '--no-trunc']) and parses each output line. The docker CLI's "live" mode keeps the cumulative counters from its initial snapshot — they don't refresh across output ticks the way the per-container /stats socket endpoint does.

I've prepared a fix that swaps the CLI spawn for a direct dockerode stats stream per container (plus subscribing to docker events to add/remove streams on start/die/stop/kill/destroy). GraphQL schema is unchanged — only the data source for the resolver. Tests follow the docker-event.service.spec.ts template.

I plan to open a Work Intent for the fix referencing this bug.

Ngôn ngữ chính
TypeScript
Star
113
Fork
23
Merge trung bình
2 ngày 15 giờ
Pull request đã merge (30 ngày)
8

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của unraid/api

Tất cả issue của unraid/api

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.