Conversation
This was referenced Sep 19, 2026
openwrt-ai
reviewed
Sep 20, 2026
choppyc79
force-pushed
the
luci-app-qosify-unknown-state
branch
from
September 20, 2026 08:11
bf30244 to
7253035
Compare
openwrt-ai
reviewed
Sep 20, 2026
openwrt-ai
left a comment
openwrt-ai
left a comment
Collaborator
There was a problem hiding this comment.
Commit checks
- 7253035 "luci-app-qosify: report an unanswered status call as unknown" — the body says the start/stop/restart/reload buttons "report the failing call's own error", but the diff makes
waitForRunning/waitForStoppedtri-state and hassvcActionraise its own "rpcd is not answering" message and skip/usr/share/qosify-luci/cleanupon an unanswered poll. Say that the service actions now fail rather than clean up when the poll goes unanswered.
Generated by Claude Code
choppyc79
force-pushed
the
luci-app-qosify-unknown-state
branch
3 times, most recently
from
September 20, 2026 18:39
2352634 to
95df3cc
Compare
openwrt-ai
reviewed
Sep 21, 2026
openwrt-ai
left a comment
openwrt-ai
left a comment
Collaborator
There was a problem hiding this comment.
Commit checks
- 95df3cc "luci-app-qosify: report an unanswered status call as unknown" — body (and the PR description) still says the cause is "named once on the Running row";
mark()now hangs the note on the first row that reads Unknown. Reword to say the first Unknown row. - 95df3cc (same) — body still says the start/stop/restart/reload buttons "report the failing call's own error", but
svcActionraises its own "rpcd is not answering" on an unanswered poll and skips/usr/share/qosify-luci/cleanupafter a stop. Say the action fails instead of cleaning up. - 95df3cc (same) —
applyService()now restarts qosify whenservice.listgoes unanswered, so a save can start a stopped qosify; the body's save paragraph only covers the shaping warning. Add a line for the restart-on-unknown fallback.
Generated by Claude Code
rpc.declare() resolves a ubus error status unless reject is set, so a
status code (6 once the session's ACL no longer covers the object, 4
when the object is gone) stays in result[0] and expect {'': {}}
rewrites it to the same {} a working call with nothing to report
returns. L.resolveDefault() cannot tell the two apart, so an ACL left
over from an older install, a stale session or a stopped rpcd reads as
a stopped, unshaped qosify with no init script.
Declare rc.list, service.list and qosify.status with reject: true and
catch each rejection to null. running, enabled, hasInit, active and
shaped are then null rather than false when the call was not answered,
and the Overview service table shows an amber Unknown badge for each,
with the cause named once, on the first row that reads Unknown. The
qosify object goes with the daemon, so an unanswered status call while
qosify is stopped still reads as not shaping.
The autostart button carries the state as its label, so it shows
Unknown and is disabled while the state is unknown. Its click now reads
the state from the last refresh rather than from when the button was
built, so a tick that changes the state also changes the action. The
start, stop, restart and reload buttons stay clickable. When the
service.list poll after a start, restart or stop goes unanswered, the
action fails with "rpcd is not answering" rather than reporting a
result it could not check, and a stop then skips
/usr/share/qosify-luci/cleanup instead of cleaning up.
A save no longer warns that qosify is not shaping when the check could
not run; it says shaping could not be checked. When service.list goes
unanswered while a save applies, qosify is restarted rather than
reloaded or started, since the config is already written and the
running state is unknown. That restart also starts a qosify that was
stopped.
The Status tab says rpcd is not answering rather than that qosify is
not running, and says the interface summary is unavailable when only
qosify status went unanswered.
updateEnBadge() gives the Config tab's QoS Enabled badge the same
treatment: with the section enabled and the status call unanswered it
reads Status Unknown, rather than the Enabled — Not Shaping (check
config) or Enabled — Not Running a null active used to fall through to.
A section disabled in UCI still reads Disabled — that state comes from
the config, not from the call, so an unanswered call does not put it in
doubt.
po/templates/qosify.pot regenerated with build/i18n-scan.pl.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signed-off-by: Ash Clarke <clarkeaj@hotmail.co.uk>
choppyc79
force-pushed
the
luci-app-qosify-unknown-state
branch
from
September 21, 2026 06:39
95df3cc to
0cda7ec
Compare
Contributor
Author
|
Folded into #9054, which carries this commit unchanged as part of the |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull request details
Description
A status call rpcd never answered currently reads as "qosify stopped, not
shaping, init script missing": rpc.declare() without reject: true turns a
ubus error (6 stale ACL, 4 object gone) into the same {} an idle daemon
returns, and L.resolveDefault() cannot tell them apart.
rc.list, service.list and qosify.status are now declared with reject: true,
and the service state is tri-state (true / false / null):
row that reads Unknown
its click follows the last refresh, not the state at build time
unanswered, the action fails with "rpcd is not answering"; a stop then
skips /usr/share/qosify-luci/cleanup instead of cleaning up
rather than reloaded or started, since the config is already written.
This also starts a qosify that was stopped
section while the status call is unanswered, in place of the Enabled —
Not Shaping / Enabled — Not Running a null active used to fall through
to. A section disabled in UCI still reads Disabled, since that state
comes from the config rather than from the call
A stopped qosify still reads as not shaping, since the qosify ubus object
goes with the daemon. No ACL change, no layout change.
Screenshot or video of changes
<Overview: normal / qosify stopped / ACL removed>
Maintainer
@choppyc79
Tested on
OpenWrt version: SNAPSHOT r36237-2ed2c210c3
LuCI version: 26.257.37274~f4eebd4
Web browser(s): Google Chrome
Checklist