Introduce automatic request cancellation

[OmarHawk]

in Angular list views, unless having infinite scroll enabled

We have noticed, that requests in list views do not get automatically canceled when the user may trigger a new request by quickly changing things like search string or removing the search string again.
The request that finishes later (can be the one started at first) will always override the resulting list. So: If you have a long running search operation (like 3-4s) and then basically remove the search parameters, a new request will be triggered for the unfiltered view again. That one most often finishes much faster than a search on a large dataset, but since the search is not canceled, it will also finish and show search results, even though the user had already removed the search... Can lead to inconsistent views of the results.

---

Please make sure the below checklist is followed for Pull Requests.

• All continuous integration tests are green
• Tests are added where necessary
• The JDL part is updated if necessary
• jhipster-online is updated if necessary
• Documentation is added/updated where necessary
• Coding Rules & Commit Guidelines as per our CONTRIBUTING.md document are followed

When you are still working on the PR, consider converting it to Draft (below reviewers) and adding skip-ci label, you can still see CI build result at your branch.

[OmarHawk]

Ah, infinite scroll won't work easily with this approach. I'll check what I can do. Maybe just having this supported for standard pagination.

[Copilot]

Pull request overview

This PR updates the generated Angular entity list component template to prevent stale HTTP responses from overwriting newer list results by canceling prior in-flight requests (except when infinite scroll is enabled).

Changes:

• Add a loadTrigger$ Subject and use switchMap to ensure only the latest queryBackend() request remains active (non–infinite scroll only).
• Route load() through loadTrigger$ for non–infinite scroll, keeping existing direct-load behavior for infinite scroll.
• Update RxJS imports accordingly.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[OmarHawk]

I'll look into the proposals :)

[mshima]

Have you considered to use httpResource instead?

[OmarHawk]

Have you considered to use httpResource instead?

Actually no. In https://angular.dev/api/common/http/httpResource it says it is still experimental, so wdyt?

[mshima]

Have you considered to use httpResource instead?

Actually no. In https://angular.dev/api/common/http/httpResource it says it is still experimental, so wdyt?

I prefer to introduce httpResource instead of the added complexity.
We will use only basic apis.
@qmonmert what do you think?

[OmarHawk]

I've looked a bit more into httpResource and it looks like it would require changes in various places (i.e. a lot of work ;-)) if we want to consistently use it everywhere.
Plus I'm not sure if that's the best "general" approach for our use cases (like also form handling). To me it looks best fitted for actual resource fetching (GET), but not for e.g. form submissions. At the moment, our service class has both - so I'm not sure, if this in the end makes things less complex tbh as we would probably require then both approaches...

[mshima]

I definitely think we should use httpResource in this case instead of the added complexity.

[OmarHawk]

I've finished the Pull Request anyway and added the remarked missing tests and error handling, just to maybe have an option in case we go for a "bugfix first" and move the imo bigger / possibly structural changes to "later".

(I guess, I'm missing time to add httpResource support/corresponding changes myself!)

[OmarHawk]

I'm just curious, if my tests pass, that's why I rebased. Would close the MR later as it is superseded by #32373

[mshima]

query is never called.

[mshima]

query is never called.