Describe the bug
This bug is a bit complex. When switching back and forth between search result pages with two different sets of sort options, where one of the search results was already visited (request cached by the frontend), the frontend sends a request to search objects using the previous search result's sort option configurations.
The best example case is switching within a person's profile between Publications -> Projects -> Publications. When Publications is revisited, the default sort from Projects is used in the query for Publications. If the default sorts of Publications and Projects do not match, revisiting publication results applies an invalid sort value in the backend request, returning a 422 error.
This bug only appears when using navigation links (Angular Router) and cached requests. Full page loads are not affected. In theory, this can affect navigation across the entire site, but it is most obvious when viewing a person's profile.
To Reproduce
Setup:
Version: 2025.02.01.01
- Have a person entity that possesses publication and project records.
- Have a completely different set of sort options configured for the person's publications vs. projects.
Steps to reproduce the behavior:
- Open a person item page that possesses publications and projects, starting, for example, on the Publications tab (this will hard-load the publications from the backend).
- Go to the Projects tab (this will hard-load the projects from the backend).
- Go back to the Publications tab. Here, the frontend will display the sort options for projects, and the backend will query publications with an invalid sort value.
Expected behavior
When switching between search results using navigation links (Angular Router), sort options should always match the search result's configuration, regardless of whether the page is hard-loaded or retrieved from cache.
Notes
The main component involved in this bug is search.component.ts. I am not an Angular or TypeScript expert, but there seems to be a problem with the observables involved and the way requests are cached. From what I understand, some observables can be asynchronous or synchronous depending on whether values are cached, causing them to emit mismatched values.
When testing a fix for this bug, I recommend using browser network throttling to ensure the fix is foolproof for production backend servers that cannot finish requests in a very short timeframe (< 500ms). I've tried some fixes that work on a local developing fast machine, but they fail when testing on a production like environment.
Describe the bug
This bug is a bit complex. When switching back and forth between search result pages with two different sets of sort options, where one of the search results was already visited (request cached by the frontend), the frontend sends a request to search objects using the previous search result's sort option configurations.
The best example case is switching within a person's profile between Publications -> Projects -> Publications. When Publications is revisited, the default sort from Projects is used in the query for Publications. If the default sorts of Publications and Projects do not match, revisiting publication results applies an invalid sort value in the backend request, returning a 422 error.
This bug only appears when using navigation links (Angular Router) and cached requests. Full page loads are not affected. In theory, this can affect navigation across the entire site, but it is most obvious when viewing a person's profile.
To Reproduce
Setup:
Version: 2025.02.01.01
Steps to reproduce the behavior:
Expected behavior
When switching between search results using navigation links (Angular Router), sort options should always match the search result's configuration, regardless of whether the page is hard-loaded or retrieved from cache.
Notes
The main component involved in this bug is
search.component.ts. I am not an Angular or TypeScript expert, but there seems to be a problem with the observables involved and the way requests are cached. From what I understand, some observables can be asynchronous or synchronous depending on whether values are cached, causing them to emit mismatched values.When testing a fix for this bug, I recommend using browser network throttling to ensure the fix is foolproof for production backend servers that cannot finish requests in a very short timeframe (< 500ms). I've tried some fixes that work on a local developing fast machine, but they fail when testing on a production like environment.