Activities of "burkay"

Hello Maliming,

Thank you for the follow up. NavigationHelper method works. So, we can wait for the fix in the framework. I intend to close this issue by then:)

You asked for the logs of our test using v9.1.1. Unfortunately, I reverted to v9.1.0 when I could not make it work and do not have the logs available now. I need to start from scratch to generate them again.

Hello again,

First of all thank you for the reply and also for the refund. We really appreciate your prompt responses.

I got the following notification in an e-mail: "Question #9039 has been marked as a bug/problem by the team, ..."

In that case, I think this solution should be built-in the ABP framework as it is considered a bug. I do not think future users should add that configuration once they started a new project using ABP.

Applying your previous suggestion (NavigationHelper), we already have a solution. In that case, what is the use of removing that and adding some other configuration? I just want to know if this will get resolved in a release, and the version number if it will.

Thank you again. Burkay

Hello,

As you wrote in your linked post, we added the following code to our EntityFrameworkCore project:

    using Microsoft.EntityFrameworkCore.ChangeTracking;
    using Volo.Abp.DependencyInjection;
    using Volo.Abp.EntityFrameworkCore.ChangeTrackers;
    using Volo.Abp.OpenIddict.Tokens;
    
    namespace Ptr.EntityFrameworkCore;
    
    [Dependency(ReplaceServices = true)]
    [ExposeServices(typeof(AbpEfCoreNavigationHelper))]
    public class PtrAbpEfCoreNavigationHelper : AbpEfCoreNavigationHelper
    {
        public override void ChangeTracker_Tracked(object? sender, EntityTrackedEventArgs e)
        {
            if (e.Entry.Entity.GetType() == typeof(OpenIddictToken))
            {
                return;
            }
    
            base.ChangeTracker_Tracked(sender, e);
        }
    
        public override void ChangeTracker_StateChanged(object? sender, EntityStateChangedEventArgs e)
        {
            if (e.Entry.Entity.GetType() == typeof(OpenIddictToken))
            {
                return;
            }
    
            base.ChangeTracker_StateChanged(sender, e);
        }
    }

With this in place, we ran some tests. We waited for half an hour in 4 tabs. All of them sent requests to connect/token twice at each 15th minute. The system does not kick users out. Thank you! Now we have two questions:

1. We still see the concurrency exception in logs: [ERR] The database operation was expected to affect 1 row(s), but actually affected 0 row(s); data may have been modified or deleted since entities were loaded. See https://go.microsoft.com/fwlink/?LinkId=527962 for information on understanding and handling optimistic concurrency exceptions. Volo.Abp.Data.AbpDbConcurrencyException: The database operation was expected to affect 1 row(s), but actually affected 0 row(s); data may have been modified or deleted since entities were loaded. See https://go.microsoft.com/fwlink/?LinkId=527962 for information on understanding and handling optimistic concurrency exceptions.

2. In your above reply, you said this will be fixed in v9.1.1. It is released, we tested using it but the error persisted. When this issue gets fixed in ABP itself, we will remove the above code from our codebase. Could you tell us in which version will this be fixed?

Thank you again and best wishes.

Hello Shiwei,

Thank you for your response.

Best, Burkay

Hello Shiwei,

I got an email saying this is closed by ServiceBot. You mentioned that you would be reaching out to the team for input, and I was wondering if there have been any updates or developments regarding it.

Thank you for your help, and I look forward to hearing back from you!

Best, Burkay

I created a new project with ABP CLI 8.3.3 as you suggested earlier. The problem is fixed. Thank you for the fix and for the refund :)

Thank you! I wlll check it as soon as possible. Meanwhile, since this required a fix on your part, could you refund our question credit?

Thank you!

Please note that if that is the case, the second rule is completely useless and unnecessarily increases the bundle size. I want to believe that it is there for a reason. We already have a workaround and just wanted to bring this to your attention. Could you also tell your teammate about this? Thank you.

Awesome, thank you!