QA review of feat/secondary-sdr-priority (server-26 3cbb082, node-26 9b6c64f), non-blocking.
Both dashboards fall back to an empty running list when the true signal is "unknown/unreachable", not "nothing running yet":
Client/drb-edge-node/app/templates/index.html:583 sdrRunning = d.running || []; then :551 computes state as enabled && !running -> 'Waiting for SDR' for every row, even when d.running === null (secondary-sdr container down). The summary line at :590 does say "Secondary SDR service is not responding", but each row still reads as a normal, self-resolving wait rather than an error.
Server/drb-frontend/components/SecondarySdrPriority.tsx:26 const running = node.secondary_sdr_running ?? [] has the same conflation when a node's checkin has never included secondary_sdr_running (pre-feature firmware) — every enabled row reads "Waiting for SDR" forever with no way to distinguish that from a genuinely spare-constrained wait.
Not blocking (no dead control, no false claim of success) but worth a distinct visual/text state (e.g. "Unknown" / "Service unreachable") per row so an admin doesn't wait on a row that will never resolve.
Filed by drb-qa-review, read-only pass, requested by owner.
QA review of feat/secondary-sdr-priority (server-26 3cbb082, node-26 9b6c64f), non-blocking.
Both dashboards fall back to an empty running list when the true signal is "unknown/unreachable", not "nothing running yet":
- Client/drb-edge-node/app/templates/index.html:583 `sdrRunning = d.running || [];` then :551 computes state as `enabled && !running -> 'Waiting for SDR'` for every row, even when `d.running === null` (secondary-sdr container down). The summary line at :590 does say "Secondary SDR service is not responding", but each row still reads as a normal, self-resolving wait rather than an error.
- Server/drb-frontend/components/SecondarySdrPriority.tsx:26 `const running = node.secondary_sdr_running ?? []` has the same conflation when a node's checkin has never included `secondary_sdr_running` (pre-feature firmware) — every enabled row reads "Waiting for SDR" forever with no way to distinguish that from a genuinely spare-constrained wait.
Not blocking (no dead control, no false claim of success) but worth a distinct visual/text state (e.g. "Unknown" / "Service unreachable") per row so an admin doesn't wait on a row that will never resolve.
Filed by drb-qa-review, read-only pass, requested by owner.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
QA review of feat/secondary-sdr-priority (server-26
3cbb082, node-26 9b6c64f), non-blocking.Both dashboards fall back to an empty running list when the true signal is "unknown/unreachable", not "nothing running yet":
sdrRunning = d.running || [];then :551 computes state asenabled && !running -> 'Waiting for SDR'for every row, even whend.running === null(secondary-sdr container down). The summary line at :590 does say "Secondary SDR service is not responding", but each row still reads as a normal, self-resolving wait rather than an error.const running = node.secondary_sdr_running ?? []has the same conflation when a node's checkin has never includedsecondary_sdr_running(pre-feature firmware) — every enabled row reads "Waiting for SDR" forever with no way to distinguish that from a genuinely spare-constrained wait.Not blocking (no dead control, no false claim of success) but worth a distinct visual/text state (e.g. "Unknown" / "Service unreachable") per row so an admin doesn't wait on a row that will never resolve.
Filed by drb-qa-review, read-only pass, requested by owner.