[
https://issues.apache.org/jira/browse/NIFI-16295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Seow Alex updated NIFI-16295:
-----------------------------
Description:
Opening a direct link to a process group sometimes results in the root process
group being displayed instead of the process group specified in the URL.
This appears to happen most often when the link is opened in a new/background
tab, for example using Ctrl+click or middle-click.
Example URL: {{https://<nifi-host>/nifi/#/process-groups/<process-group-id>}}
The user is already authenticated when this occurs, so this does not appear to
be related to the login/deep-link redirect issue.
Refreshing the affected tab generally causes the correct process group to load.
*Steps to reproduce*
# Log in to NiFi.
# From another page, open a direct NiFi process-group URL in a new background
tab:
{{https://<nifi-host>/nifi/#/process-groups/<non-root-process-group-id>}}
# Switch to the new tab shortly after opening it.
# Repeat if necessary, as the issue appears timing-dependent.
*Actual behavior*
The root process group is sometimes loaded instead of the process group
specified in the route.
Refreshing the page while the tab is visible usually loads the correct process
group.
*Expected behavior*
The process group specified by the {{processGroupId}} route parameter should
always be loaded.
*Suspected cause*
_Disclaimer: The following was investigated with the assistance of LLMs._
There appears to be a race between the initial process-group load and the
document visibility reload logic.
On a new page, the flow state is initially: {{{}id: 'root'{}}}.
The canvas reads the process-group ID from the route and dispatches:
{{loadProcessGroup(<route-process-group-id>)}}
However, the flow state's {{id}} is not updated to the requested process-group
ID until {{{}loadProcessGroupSuccess{}}}.
If the tab transitions from hidden to visible before the initial request
completes, the document visibility logic may dispatch: {{reloadFlow()}}
{{reloadFlow}} currently obtains the process-group ID from:
{{selectCurrentProcessGroupId}}
which at that point can still return: {{root}}
This can result in: {{loadProcessGroup(<route-id>)
loadProcessGroup("root")}}
The second action can supersede the first load, causing the root process group
to be displayed.
This would also explain why:
* the issue is intermittent;
* it occurs more frequently with new/background tabs;
* refreshing the page while the tab is already visible normally resolves it.
was:
*Description*
Opening a direct link to a process group sometimes results in the root process
group being displayed instead of the process group specified in the URL.
This appears to happen most often when the link is opened in a new/background
tab, for example using Ctrl+click or middle-click.
Example URL: {{https://<nifi-host>/nifi/#/process-groups/<process-group-id>}}
The user is already authenticated when this occurs, so this does not appear to
be related to the login/deep-link redirect issue.
Refreshing the affected tab generally causes the correct process group to load.
*Steps to reproduce*
# Log in to NiFi.
# From another page, open a direct NiFi process-group URL in a new background
tab:
{{https://<nifi-host>/nifi/#/process-groups/<non-root-process-group-id>}}
# Switch to the new tab shortly after opening it.
# Repeat if necessary, as the issue appears timing-dependent.
*Actual behavior*
The root process group is sometimes loaded instead of the process group
specified in the route.
Refreshing the page while the tab is visible usually loads the correct process
group.
*Expected behavior*
The process group specified by the {{processGroupId}} route parameter should
always be loaded.
*Suspected cause*
_Disclaimer: The following was investigated with the assistance of LLMs._
There appears to be a race between the initial process-group load and the
document visibility reload logic.
On a new page, the flow state is initially: {{{}id: 'root'{}}}.
The canvas reads the process-group ID from the route and dispatches:
{{loadProcessGroup(<route-process-group-id>)}}
However, the flow state's {{id}} is not updated to the requested process-group
ID until {{{}loadProcessGroupSuccess{}}}.
If the tab transitions from hidden to visible before the initial request
completes, the document visibility logic may dispatch: {{reloadFlow()}}
{{reloadFlow}} currently obtains the process-group ID from:
{{selectCurrentProcessGroupId}}
which at that point can still return: {{root}}
This can result in: {{loadProcessGroup(<route-id>)
loadProcessGroup("root")}}
The second action can supersede the first load, causing the root process group
to be displayed.
This would also explain why:
* the issue is intermittent;
* it occurs more frequently with new/background tabs;
* refreshing the page while the tab is already visible normally resolves it.
> NiFi UI may load the root process group instead of a deep-linked process
> group when opening the link in a new tab
> -----------------------------------------------------------------------------------------------------------------
>
> Key: NIFI-16295
> URL: https://issues.apache.org/jira/browse/NIFI-16295
> Project: Apache NiFi
> Issue Type: Bug
> Reporter: Seow Alex
> Priority: Minor
>
> Opening a direct link to a process group sometimes results in the root
> process group being displayed instead of the process group specified in the
> URL.
> This appears to happen most often when the link is opened in a new/background
> tab, for example using Ctrl+click or middle-click.
> Example URL: {{https://<nifi-host>/nifi/#/process-groups/<process-group-id>}}
> The user is already authenticated when this occurs, so this does not appear
> to be related to the login/deep-link redirect issue.
> Refreshing the affected tab generally causes the correct process group to
> load.
> *Steps to reproduce*
> # Log in to NiFi.
> # From another page, open a direct NiFi process-group URL in a new
> background tab:
> {{https://<nifi-host>/nifi/#/process-groups/<non-root-process-group-id>}}
> # Switch to the new tab shortly after opening it.
> # Repeat if necessary, as the issue appears timing-dependent.
> *Actual behavior*
> The root process group is sometimes loaded instead of the process group
> specified in the route.
> Refreshing the page while the tab is visible usually loads the correct
> process group.
> *Expected behavior*
> The process group specified by the {{processGroupId}} route parameter should
> always be loaded.
> *Suspected cause*
> _Disclaimer: The following was investigated with the assistance of LLMs._
> There appears to be a race between the initial process-group load and the
> document visibility reload logic.
> On a new page, the flow state is initially: {{{}id: 'root'{}}}.
> The canvas reads the process-group ID from the route and dispatches:
> {{loadProcessGroup(<route-process-group-id>)}}
> However, the flow state's {{id}} is not updated to the requested
> process-group ID until {{{}loadProcessGroupSuccess{}}}.
> If the tab transitions from hidden to visible before the initial request
> completes, the document visibility logic may dispatch: {{reloadFlow()}}
> {{reloadFlow}} currently obtains the process-group ID from:
> {{selectCurrentProcessGroupId}}
> which at that point can still return: {{root}}
> This can result in: {{loadProcessGroup(<route-id>)
> loadProcessGroup("root")}}
> The second action can supersede the first load, causing the root process
> group to be displayed.
> This would also explain why:
> * the issue is intermittent;
> * it occurs more frequently with new/background tabs;
> * refreshing the page while the tab is already visible normally resolves it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
