fix: platform automation context missing applicationId/instanceId on device pages - #7995
Open
andypalmi wants to merge 3 commits into
Open
fix: platform automation context missing applicationId/instanceId on device pages#7995andypalmi wants to merge 3 commits into
andypalmi wants to merge 3 commits into
Conversation
added 3 commits
July 28, 2026 15:55
The platform automation context getter derived applicationId by matching the route path against "/applications/", which is never true on device- or instance-overview pages. Prefer the owning application already loaded on state.device/state.instance before falling back to the route-based check.
… on device-group pages The platform automation context getter checked state.device/state.instance for an owning application but never state.application, even though application-overview pages already populate it. Device-group pages (:applicationId/device-group/:deviceGroupId) never registered their application with the context store at all and use a differently-named route param, so applicationId resolved to null there regardless.
…ner, expose deviceOwnerType instanceId only checked the route path, which is never true on a device page, so a device owned by an instance never surfaced its instanceId even though applicationId (transitively, via the instance) did - same class of bug as applicationId, mirrored here. The device page now also registers its actual owner (application or instance) with the context store directly, matching what the application/instance overview pages already do for themselves, and the context sent to the assistant now includes deviceOwnerType so it can tell a device directly owned by an application apart from one owned by an instance without inferring it from which ID is present.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #7995 +/- ##
=======================================
Coverage 75.86% 75.86%
=======================================
Files 434 434
Lines 23340 23340
Branches 6209 6209
=======================================
Hits 17708 17708
Misses 5632 5632
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
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
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.
Closes FlowFuse/engineering#214
Where the issue was
useContextStore'sexpertgetter (frontend/src/stores/context.js) builds thecontextobject sent with every chat query and returned by theui_get_contextautomation tool.applicationIdandinstanceIdwere both derived by string-matching the current route (/applications/,/instance/) and readingroute.params.id- which is never true on a device-overview page, so both came backnullwhenever a device was open, even though the device has a known owning application or instance. The same route-string approach also missedstate.application, which application-overview pages already populate, and missed device-group pages entirely (:applicationId/device-group/:deviceGroupId, which never registered anything with the context store and use a differently-named route param).How it's fixed
applicationIdnow prefers the owning application already loaded onstate.device/state.instance, thenstate.application, before falling back to the route-string check.instanceIdnow prefers the owning instance loaded onstate.devicebefore falling back to the same route-string check.application/DeviceGroup/index.vueregisters its loaded application with the context store (mirroring what the application-overview page already does), fixing the missing-param-name case.device/index.vuenow also registers the device's actual owner (application or instance) directly with the context store, matching the pattern application/instance overview pages already use for themselves.deviceOwnerTypeso a device directly owned by an application can be told apart from one owned by an instance without inferring it from which ID happens to be present.Test plan
ui_get_contextand the chat context return the device's actualapplicationId(previouslynull).instanceId(previouslynull) and the instance's owningapplicationIdare both returned, withdeviceOwnerType: "instance"disambiguating the two IDs.