Describe the bug
When viewing a Fusion app with a specific tag (e.g. a commit SHA or build tag), the tag is reflected in the URL as a query parameter (e.g. ?tag=<commit-sha>). If the user then navigates to a different app — for example the Fusion App Admin — the tag parameter is carried over into the destination URL.
The destination app does not have a build for that tag/commit combination, so the navigation fails (the app cannot be loaded for that tag).
Environment
- OS: N/A (browser-based, reproducible on all platforms)
- Node Version: N/A (runtime issue)
To Reproduce
- Open a Fusion app that has been deployed with a specific tag (e.g. a feature-branch build).
- Observe that the URL contains a
tag query parameter (e.g. https://<portal>/<app>?tag=<commit-sha>).
- Navigate to a second, unrelated app (e.g. Fusion App Admin) — either by clicking a link in the portal or by manual navigation.
- Observe that the destination URL also contains the same
tag query parameter.
- The second app fails to load because no build exists for that tag.
Expected behavior
The tag query parameter should be scoped to the app it was applied to. When navigating to a different, independent app, the tag parameter must not be forwarded. Each app should resolve its own tag independently (defaulting to its latest/published build when no explicit tag applies to it).
Stacktrace
N/A — the failure manifests as the target app silently failing to load or returning a 404/error when the framework tries to fetch the build artifact for the forwarded tag.
Additional context
- The
tag parameter is intentionally supported for canary/preview builds of a single app.
- The problem arises in the portal's cross-app navigation logic: the tag is treated as global URL state rather than per-app state.
- Likely root cause: the framework's router or app-switcher propagates
tag as part of the shared query string when constructing the destination URL, rather than stripping app-specific parameters before leaving the source app.
- Possible fix: strip (or refuse to forward) the
tag parameter when navigating away from the originating app, or maintain a per-app tag map in portal state rather than encoding it as a shared URL parameter.
Describe the bug
When viewing a Fusion app with a specific tag (e.g. a commit SHA or build tag), the tag is reflected in the URL as a query parameter (e.g.
?tag=<commit-sha>). If the user then navigates to a different app — for example the Fusion App Admin — the tag parameter is carried over into the destination URL.The destination app does not have a build for that tag/commit combination, so the navigation fails (the app cannot be loaded for that tag).
Environment
To Reproduce
tagquery parameter (e.g.https://<portal>/<app>?tag=<commit-sha>).tagquery parameter.Expected behavior
The
tagquery parameter should be scoped to the app it was applied to. When navigating to a different, independent app, the tag parameter must not be forwarded. Each app should resolve its own tag independently (defaulting to its latest/published build when no explicit tag applies to it).Stacktrace
N/A — the failure manifests as the target app silently failing to load or returning a 404/error when the framework tries to fetch the build artifact for the forwarded tag.
Additional context
tagparameter is intentionally supported for canary/preview builds of a single app.tagas part of the shared query string when constructing the destination URL, rather than stripping app-specific parameters before leaving the source app.tagparameter when navigating away from the originating app, or maintain a per-app tag map in portal state rather than encoding it as a shared URL parameter.