Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

dockerContainerStats subscription returns frozen NetIO/BlockIO values

オープン
  • 何か問題がありますか？
#2,007 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
静か
技術スタック
docker, graphql, typescript
領域
api, backend

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
TypeScript
スター
113
フォーク
23
平均マージ
2日 15時間
マージ済み PR（30日）
8

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

unraid/api のほかの issue

unraid/api の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。