You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The correlation ID should be moved to the ngrx store
That initializer function should check if there's a correlation ID in the store. If there is it shouldn't do anything. If there isn't, it should check if there's a cookie and init the store with it, or generate a new ID and put that in the store
The interceptor should get the value from the store
The interceptor should check if the id exists before adding it as a header, to ensure we don't get undefined headers
That last part is the critical thing to get rid of the symptoms, so I'll create a small PR to add that check, and some better error logging for these kinds of issues.
Until we fix the other parts, we won't get correlation IDs for the very first request of a client with JS, or for any request of a client without JS.
The rest can be done in an estimated 3 hours (moved to #1281)
I already spent 2 hours on analysis. (this was the work done in #1280)
To prevent similar issues it may also be a good idea to remove the 'set' and 'remove' methods from the cookieservice interface, and implement them only on ClientCookieService. That way you need to be sure you're on the client before calling them. I tried throwing an exception when these methods are called server-side in my PR, but that happens a lot, so that would litter the logs with unnecessary warnings.
Describe the bug
The log interceptor gets the correlation ID from the cookie and adds it as a request header. However if you set a request header that's undefined, HttpClient will crash when sending the request.
If it doesn't exist, a correlation ID is generated in an APP_INITIALIZER function, and stored as a cookie. But you can't store cookies server side, that method isn't implemented
To Reproduce
Expected behavior
That last part is the critical thing to get rid of the symptoms, so I'll create a small PR to add that check, and some better error logging for these kinds of issues.
Until we fix the other parts, we won't get correlation IDs for the very first request of a client with JS, or for any request of a client without JS.
The rest can be done in an estimated 3 hours (moved to #1281)
I already spent 2 hours on analysis. (this was the work done in #1280)
To prevent similar issues it may also be a good idea to remove the 'set' and 'remove' methods from the cookieservice interface, and implement them only on ClientCookieService. That way you need to be sure you're on the client before calling them. I tried throwing an exception when these methods are called server-side in my PR, but that happens a lot, so that would litter the logs with unnecessary warnings.
Related work
Introduced by #1255
The text was updated successfully, but these errors were encountered: