There's an angular project at work.

I guess they know about as much about angular as I do (not much)

Because the error page isn't working, so when you get an error, you infinite loop and DDoS yourself.

It actually crashes my (admittedly subpart) desktop.

Guess I'll be learning how to fix that.

Is it happening within angular router or is it actually redirecting the browser?

@SortOfTested Pretty sure it's the router.

The current angular project I‘m working on uses an UI library that somehow broke the rendering pipeline and they „fixed“ it by forceful Dom diffing on mouse move.

I’ve once waited 20 minutes looking at a spinner because my cursor was on a different screen.

Oh and we also get randomly redirected to other pages when a error occurs, usually the login page, even though you already are logged in

@AlgoRythm
There's two ways to solve this. One won't be a protection against future issues, so I won't share it.

- Create a CircularRouteDetection service that internalizes a ReplaySubject<string> with a cache size of 10, inject at root. Add a scan operator to fold the values into a continuously updated array of the last N values.
- Create an Observable property (CircularRouteDetected$) that maps the values into a boolean by detecting whether or not a two pair route pattern has been seen N or more times (3 would be my initial K, eventually should be configurable)
- Create a CanActivateGuard class (ideally named CircularDetectionActivationGuard) and add it to the root of your route configuration trees(https://angular.io/guide/cheatsheet)
- Inject the CircularRouteDetection service into the CanActivateGuard
- In the canActivate method, subscribe to the CircularRouteDetected$ stream, using a take(1) operator to only sample one value...

- evaluate the boolean result of the pipe in question and either allow the activation, or redirect to a global circular route detected route

This means you will always detect these occurrences, and know which routes are failing. Bonus, the subject member composition will tell you exactly where the loop is occurring.

@SortOfTested Looks like I'm pouring through Angular docs all day tomorrow then.

They don't pay me enough for such a good solution, but I'll get my value out by learning how to do that on their dime.

@AlgoRythm
Indeed

I am pretty novice at Angular too, so I'm not sure it will help, but could the problem be a changeDetection i-loop? Kind of like events firing events and so on.

Here's a good article on it: https://mattspaulding.org/The-Curio...

@SortOfTested I'm reading the dependency injection docs and I just created the CircularRouteDetectionService

Here is the error that happens (project name censored for no particular reason):

@AlgoRythm
Looks like your interceptor is the culprit. It's firing over and over again, check for a retry operator.

@SortOfTested interceptor?

Also, why add a scan operator? It looks like scan is an accumulator?

Our skill levels are on different planets

@AlgoRythm
The thing that seems to be blowing up is the HTTP interceptor. I don't see any angular route navigations in that error sequence, just a bunch of recurrent XHR requests.

@SortOfTested okay... I will read about angular interceptors

@AlgoRythm
To the answer for scan, scan is an accumulator that emits every time it updates the value. Reduce will continue folding until the source observable sends a complete signal and then return the value.

@SortOfTested my head is spinning

@SortOfTested I found the interceptor and looked at the endpoint. The problem was that the endpoint needed auth (Which I had suspected from the beginning, because 401).

I feel good after about 4 hours of pure document reading and experimenting this morning. Maybe one day I will even learn to love Angular.

@AlgoRythm
It's pretty great, but it has a lot of things to learn.

Made this up for you, a simpler example of circular route detection:

https://stackblitz.com/github/...

@SortOfTested wow, that's great, thank you!