That is not awesome, is ticket CS0004528159 still open on this one for you or have they closed it?
I really do hate to involve my CAM in support but this ticket has been a gong show from the start and if I am just being given a junk response because I called them out refusing to respond it will not improve my opinion of how they are handling this.
Sounds about right, a week+ waiting for an update.
I was going to wait till next week to bug them again, it was Thanksgiving after all.
I understand the âits thanksgivingâ but when you support an international user base you need to have things happening, our thanksgiving was a month and a half ago so when a major multi-national tells me they donât have anyone because of the holiday I scratch my head.
This is the PRB it is currently linked to: PRB0255752
So they linked it to the same one they linked mine to but now claim it is not connected.
Unless I am missing something that problem doesnât seem to be the same issue, unless this issue has been going on with browser based sessions since 2022 since that is when the problem record started.
Yes its been going on since the beginning.
Just to clarify before I deploy my inner Karen to my CAM/Support.
You use local AD for SSO authentication and when using the Browser in 2024.1.* as well as 2024.2.*, everything works fine until users hit the approx 4 hour mark, at which point their session is ended without reconnecting the session and you basically need to close everything down and relaunch it?
No we are integrated with Azure AD. I am having a variety of problems but none I have precisely pinned down to a 4 hour mark.
The first time I try to access any of our environments in the browser for the day, I get a âcanât connect to serverâ slideout. I also get that slideout at other times throughout the day but its not reproducible on demand (its totally reproducible if support would just shadow me for a day :)).
At other times, it takes me through the login process and appears to succeed, but then I just get a white screen, nothing will load. When I look in the console I see
At other times after the login process completes, it just comes back to the login page (endless loop).
Sometimes when I am in the middle of actively working, I get a message that I have been logged out due to inactivity, and all my unsaved work is lost. I then have to start the process all over again.
I have reported these various issues in different tickets but never gotten any clear answers or solutions. The last information I got from support is:
" Based on my research it appears there are a couple of different related problems that were reported. It does not look like all of them made it into the current GA code. I am getting more information on where these fixes are really addressed and will provide an update as soon as I can get that straightened out. "
That is the most promising response Iâve gotten on all the tickets put together, so I am hopeful that at some point something will be fixed.
Forgot one, I go through the login process, and then get this:
Very interesting. HTTP Response 429 means you getting rate limited. Growth Book is an open source observability tool.
GrowthBook - Open Source Feature Flags and A/B Tests
It collects information using feature flags to see how the product performs under different circumstances. Maybe the tool is blocking normal operation when too much data is dumped to them. 
So it seems like our issues may be related but probably have more differences than commonality.
I donât have any issues with the session other than an apparent time out at 4 hours.
I have this issue since switching to Azure AD integration since May 2024. We were on 2024.1.6. We are now running 2024.2.10 and still seeing the same issue. Infact the issue seems to be more frequent than before. My case has been open since June 2024 and they brushed it off saying RB0255752 already exists which they canât seem to fix. So us users continue to suffer.
Bummer. Weâve been holding off on switching to SSO for Epicor because of this.
Nathan A. from support was able to adjust our IDP timeout to 10 hours for us to eliminate this issue. Since we are cloud we had no visibility to this setting ourselves.
