NMD-789 - Nomad UI Clients view issue in federated clusters configuration

[navyadas-dev]

Description

NMD-789 - Nomad UI Clients view issue in federated clusters configuration

This PR implements the short-term solution mentioned in the ticket.

• It updates the /clients/index page to track all in-flight (incomplete) requests and cancel them when the route is exited.

Testing & Reproduction steps

Issue:

When the user is on /clients or any page, the page can initiate multiple in-flight requests for node allocation data. Some of these requests may still be pending when the user navigates away from the page.

Cause:

Those requests are not always explicitly canceled when leaving /clients, so the browser can continue holding pending requests briefly after navigation starts.

Fix:

I added explicit watcher cancellation in deactivate() to ensure cleanup always happens when leaving the Clients page.

File Modified: ui/app/routes/clients/index.js

Testing Results

Network throttling: 3G

Browser: Chrome with DevTools open

Monitoring: Network tab + Console logs

BEFORE

Before.mov

Navigate to Clients page → wait 2-3 seconds → navigate to Jobs - 0.40ms to complete deactivation

AFTER

after.mov

Navigate to Clients page → wait 2-3 seconds → navigate to Jobs - 0.30ms to complete deactivation

Observation: Minimal Difference

As the long-term solution involves backend changes to create the /v1/client-statuses endpoint, please let me know if there are any UI changes needed— happy to help with those.

Links

https://hashicorp.atlassian.net/browse/NMD-789

Contributor Checklist

• Changelog Entry If this PR changes user-facing behavior, please generate and add a
  changelog entry using the make cl command.
• Testing Please add tests to cover any new functionality or to demonstrate bug fixes and
  ensure regressions will be caught.
• Documentation If the change impacts user-facing functionality such as the CLI, API, UI,
  and job configuration, please update the Nomad product documentation, which is stored in the
  web-unified-docs repo. Refer to the web-unified-docs contributor guide for docs guidelines.
  Please also consider whether the change requires notes within the upgrade
  guide. If you would like help with the docs, tag the nomad-docs team in this PR.

Reviewer Checklist

• Backport Labels Please add the correct backport labels as described by the internal
  backporting document.
• Commit Type Ensure the correct merge method is selected which should be "squash and merge"
  in the majority of situations. The main exceptions are long-lived feature branches or merges where
  history should be preserved.
• Enterprise PRs If this is an enterprise only PR, please add any required changelog entry
  within the public repository.

• If a change needs to be reverted, we will roll out an update to the code within 7 days.

Changes to Security Controls

Are there any changes to security controls (access controls, encryption, logging) in this pull request? If so, explain.

[hashicorp-cla-app]

All committers have signed the CLA.

[tgross]

@navyadas-dev your PR says what you changed but not why that solves the problem or how to reproduce or test the problem. This is a public repo, so we need to show our work.

[navyadas-dev]

@navyadas-dev your PR says what you changed but not why that solves the problem or how to reproduce or test the problem. This is a public repo, so we need to show our work.

I had already added testing details in the ticket comments, and I’ve now included some additional information in the PR description as well. Please take another look when you get a chance, and let me know if anything else is missing or needs further clarification. Thank you!

[tgross]

Cross-posting from https://hashicorp.atlassian.net/browse/NMD-789?focusedCommentId=974394

I tried implementing the short-term solution for this issue

Issue:
When the user is on /clients or any page, the page can initiate multiple in-flight requests for node allocation data. Some of these requests may still be pending when the user navigates away from the page.

Cause:

Those requests are not always explicitly canceled when leaving /clients, so the browser can continue holding pending requests briefly after navigation starts.

Fix:
I added explicit watcher cancellation in deactivate() to ensure cleanup always happens when leaving the Clients page.
File Modified: ui/app/routes/clients/index.js

Testing Results

Network throttling: 3G
Browser: Chrome with DevTools open
Monitoring: Network tab + Console logs

BEFORE
Navigate to Clients page → wait 2-3 seconds → navigate to Jobs - 0.40ms to complete deactivation

AFTER
Navigate to Clients page → wait 2-3 seconds → navigate to Jobs - 0.30ms to complete deactivation

Observation: Minimal Difference
As the long-term solution involves backend changes to create the /v1/client-statuses endpoint, please let me know if there are any UI changes needed— happy to help with those.

[tgross]

BEFORE
Navigate to Clients page → wait 2-3 seconds → navigate to Jobs - 0.40ms to complete deactivation
AFTER
Navigate to Clients page → wait 2-3 seconds → navigate to Jobs - 0.30ms to complete deactivation

I'm not sure we've really reproduced the original problem here, have we? #25920 talks about deactivation but the Jira seems to suggest there's a user-visible problem, which sounds like a lot more than 0.4ms.

As the long-term solution involves backend changes to create the /v1/client-statuses endpoint,

You haven't explained this in the PR either, so I'll copy-paste from the Jira what this is referring to:

Long-term solution: We (additionally) build what we built for the jobs index page last year, a special /statuses endpoint, but for clients. This gives us a lighter-weight endpoint that we can possibly track multiple nodes on at once.

[navyadas-dev]

BEFORE
Navigate to Clients page → wait 2-3 seconds → navigate to Jobs - 0.40ms to complete deactivation
AFTER
Navigate to Clients page → wait 2-3 seconds → navigate to Jobs - 0.30ms to complete deactivation

I'm not sure we've really reproduced the original problem here, have we? #25920 talks about deactivation but the Jira seems to suggest there's a user-visible problem, which sounds like a lot more than 0.4ms.

As the long-term solution involves backend changes to create the /v1/client-statuses endpoint,

You haven't explained this in the PR either, so I'll copy-paste from the Jira what this is referring to:

Long-term solution: We (additionally) build what we built for the jobs index page last year, a special /statuses endpoint, but for clients. This gives us a lighter-weight endpoint that we can possibly track multiple nodes on at once.

This PR implements the short-term fix . As the long-term solution involves backend changes to create the /v1/client-statuses endpoint, please let me know if any UI changes are needed — happy to help with those.

[navyadas-dev]

@jrasell As discussed could you please help to provide a large data setup to validate this implementation in more detail? I’d like to test the behavior under heavier load conditions.