Skip to content

fix: platform automation context missing applicationId/instanceId on device pages - #7995

Open
andypalmi wants to merge 3 commits into
mainfrom
fix/expert-context-missing-application-id
Open

fix: platform automation context missing applicationId/instanceId on device pages#7995
andypalmi wants to merge 3 commits into
mainfrom
fix/expert-context-missing-application-id

Conversation

@andypalmi

@andypalmi andypalmi commented Jul 28, 2026

Copy link
Copy Markdown
Contributor

Closes FlowFuse/engineering#214

Where the issue was

useContextStore's expert getter (frontend/src/stores/context.js) builds the context object sent with every chat query and returned by the ui_get_context automation tool. applicationId and instanceId were both derived by string-matching the current route (/applications/, /instance/) and reading route.params.id - which is never true on a device-overview page, so both came back null whenever a device was open, even though the device has a known owning application or instance. The same route-string approach also missed state.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

  • applicationId now prefers the owning application already loaded on state.device/state.instance, then state.application, before falling back to the route-string check.
  • instanceId now prefers the owning instance loaded on state.device before falling back to the same route-string check.
  • application/DeviceGroup/index.vue registers its loaded application with the context store (mirroring what the application-overview page already does), fixing the missing-param-name case.
  • device/index.vue now 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.
  • The context now includes deviceOwnerType so 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

  • Device owned directly by an application: ui_get_context and the chat context return the device's actual applicationId (previously null).
  • Device owned by an instance: instanceId (previously null) and the instance's owning applicationId are both returned, with deviceOwnerType: "instance" disambiguating the two IDs.
  • Application-overview page and its nested tabs.
  • Device-group page under an application.

andypalmi 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

codecov Bot commented Jul 28, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 75.86%. Comparing base (ca3c665) to head (5490cab).

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           
Flag Coverage Δ
backend 75.86% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@andypalmi
andypalmi requested a review from cstns July 28, 2026 15:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant