Repository navigation
Devices list throws error: can't access property "join", d.added_packages is null #40
Description
I've been trying to install lldp on my three connected OpenWRT devices using the oonfeeWRT webinterface.
Unfortuantely I now get the following error when trying to access the device's pages:
This screen could not render: can't access property "join", d.added_packages is null. Other controller screens remain available.
Metadata
Metadata
Assignees
Labels
No labels
Activity
aiden0rchad commentedon Sep 17, 2026
Thanks for reporting this issue, i was able to reproduce the issue and trying to find the best solution to this, I may have a fix it for this issue but i would to validate this with your setup first before pushing this to main.
aiden0rchad commentedon Sep 17, 2026
The proposed fix is ready in #41, and all CI checks passed.
The crash happens when the LLDP installation record has no newly added packages: the API can return
added_packages: null, but the Devices page treated it as an array. The PR normalizes those API responses and makes the UI tolerate null, missing, and empty package lists. It also avoids claiming the package was pre-existing when the record cannot prove that.Regression coverage includes reopening LLDP details and refreshing after installation. Local validation passed 563 UI tests and 58 browser tests, plus the LLDP API/daemon checks. I could not validate this build on the physical lab routers because the wired connection is currently unavailable.
@andreas5232, could you test the PR build and confirm that Devices loads and that opening LLDP capability / installation details no longer crashes? You should not need to reinstall LLDP just to check this. If an actual installation error remains, please share the controller version, router model/OpenWrt version, and the displayed error with credentials removed. This PR fixes the screen crash; it does not assume every possible LLDP installation error has the same cause.
Leaving this issue open for your verification.
flubba commentedon Sep 17, 2026
Not the original reporter, but I hit the same crash and can add a second data point.
Why I am affected
One of my adopted devices carries an LLDP install record whose
added_packagesis stored as SQLNULL(lldpd was already present at install time). On the build I tested before this PR,GET /api/v1/devices/<id>/capabilities/lldpreturns:{"state":"installed","requested_packages":["lldpd"],"added_packages":null,"package_manager":"apk"}Two other devices in the same controller return
"added_packages": []for the same endpoint, so only the record written when lldpd already existed carries thenull. Thatnullis what the Devices screen then tries to.join().Build provenance
codex/issue-40-lldp-null-packagesat9be9b4612363…, no local modifications.deploy/Dockerfile, taggedv0.1.7-pr41-9be9b46. Compose and environment unchanged.Results
can't access property "join"."added_packages": []instead ofnull.[]are unchanged, and a device that really did receive packages still reports them:["libcap","libevent2-7","lldpd"]. The normalization neither invents nor hides anything./healthz= 200, no errors in the log.Environment
Confirmed fixed from my side.
Testing and this write-up done with Claude Code; the hardware and the controller are mine.
andreas5232 commentedon Sep 17, 2026
Unfortunately I'm currently running your prebuilt docker images and have no build environment at hand.
So I would trust @flubba when he confirms it as fixed and wait for the next release.
aiden0rchad commentedon Sep 18, 2026
v0.1.8 is now published with the Devices/LLDP rendering fix from #41: release and downloads.
@andreas5232, no local build environment is needed: the prebuilt Docker image is
ghcr.io/aiden0rchad/oonfeewrt:v0.1.8for Linux amd64/arm64. Standalone Linux and macOS binaries are also available. Follow the upgrade and backup guide, retaining your existing data volume and runtime passphrase; do not run two controllers against the same database.Thank you, @flubba, for independently confirming the exact PR build against a genuine null LLDP package record. The release normalizes empty package lists and makes the UI tolerate legacy null/missing values. It preserves recorded package names and any real LLDP operation error; it does not assume every underlying package-installation problem is fixed.
After upgrading, refresh the browser and open Devices and the affected device's LLDP details. No LLDP reinstall, re-adoption, or database reset is required for this rendering fix. Could you confirm whether v0.1.8 resolves the crash? If an installation error remains, please include the router model, OpenWrt version, and sanitized displayed error. Leaving this issue open pending your verification.
aiden0rchad commentedon Sep 18, 2026
Thanks, @andreas5232 and @flubba. Closing this Devices-page crash as fixed by #41, now shipped in v0.1.8, based on the confirmed fix against a genuine null LLDP record and the original reporter's acceptance of that verification.
The prebuilt image is
ghcr.io/aiden0rchad/oonfeewrt:v0.1.8; no source build is required. Upgrade using the documented backup precautions and refresh the browser. No LLDP reinstall or re-adoption is needed for this rendering fix.If the same crash persists on v0.1.8, please comment and we can reopen this issue. A separate LLDP installation/service error may still require diagnosis; this closes the reported null-package-list rendering crash specifically.