In fact I remember now that the IOnlineClientStore has had its generic implementations removed and to upgrade from 13.1.0 to 13.4.0 we had to make changes to the code to make it work with the new implementations.
I suspect there has been some performance impacts introduced here that is causing our problems.
We have the chat hub disabled as we don't use chat, however we have our own application specific hub as well as the abpcommonhub.
Typically we'd have a lot of clients online as well (up to 2000).
The one thing we do use is the Redis backplane for SignalR. Has something changed in that space?
We're seeing issues when we deploy as well with redis timeouts? We've never had this problem before.
Hi @oguzhanagir,
The only login we have enabled in the appsettings.json is the JwtBearer login.
AllowSocialLoginSettingsPerTenant is also set to false.
Thanks
Narrowing the problem some more.
changeTimeZone is still changing the date IF your localtimezone is before the timezone you are converting to.
This is because the below code converts to a DateTime object which is in the correct timezone and at the start of the day in that timezone, into your local machines time with toJSDate() which puts it to the previous day. In this case the date-range-picker-luxon-modifer then says the date has changed again and away you go endless loop.
return DateTime.fromObject({ year: year, month: month, day: day, hour: hour, minute: minute, second: second }, { zone: ianaTimezoneId }).toJSDate();
Looking at this further it is still related to this change I believe
https://github.com/aspnetzero/aspnet-zero-core/pull/4723/files
The date-range-picker-luxon-modifier.directive.ts is still changing the dates when it's changing the timezones. I think. It then causes it to endlessly fire and go back in time.
Hi @ismcagdas
Has this been resolved at all. We are still seeing this issue in version 13.
The issue happens for us in this situation.
ClockProviders.UTC is set.
In a particular tenant the timezone is set to a value that is greater than my local timezone.
Eg: I'm in Australia, so my timezone is UTC+10. My tenant is in New Zealand they are UTC+12.
If I login to the tenant that is NZ and go to the audit logs and change the date range, I get this endless looping issue.
If I login to a tenant that is in Singapore (UTC+8). The issue doesn't occur.
I have confirmed that 13.1.0 and the latest preview VS works again.
Thank you :) We're still going through our full round of testing and updates to our project to 13.1.0. Will let you know if we find anything else. I'm watching that github issue now.
Thanks. Understood :)
Thanks.
We've worked around KTCard for now. However for anyone who stumbles on this support ticket at a later date.
Please note the following issue with v13.1.0, which is a problem if you are using features and redis caching.
https://support.aspnetzero.com/QA/Questions/11899/Feature-Management-Not-Working-When-Redis-Cache-Enabled-In-v1310
I've also added a third item to the list above we are still working on.
