AbpDbConcurrencyException in AbpOpenIddictTokenStore.UpdateAsync/CreateAsync, ~100+/day at fixed minute marks (ABP 10.4.1) #10925

3 Answer(s)

• 

  0

  AI-Bot created 18 hours ago

  Support Team ABP Agent

  • What you’re seeing is a real EF Core optimistic-concurrency race inside the OpenIddict token persistence flow (typically: two parallel operations touching the same token(s), e.g., refresh-token reuse/redeem + revoke-by-authorization). EF Core then throws DbUpdateConcurrencyException, and ABP wraps it as AbpDbConcurrencyException.
    The problematic part in your case is that the ABP exception is not being converted back into OpenIddict’s expected OpenIddictExceptions.ConcurrencyException, so it can bubble up and be logged as an application error (and sometimes surface as unhandled if it escapes the /connect/* pipeline).

  • There is a closely related, confirmed ABP issue in the /connect pipeline where the request UOW could complete after the response is flushed, causing timing/race problems around OpenIddict/Identity Session persistence; ABP fixed that by completing the request UOW before flushing /connect responses (included in later versions; PR below). While that specific ticket is about AbpSessions, it demonstrates ABP has been actively fixing /connect-pipeline timing/race behaviors, and your symptoms (fixed “minute marks”, steady background traffic, and concurrency exceptions in OpenIddict store) fit the same class of problems: background/automated clients + token rotation/revocation + concurrent writes.

  1) Known issue / fix / workaround

  Verified fix exists for /connect request timing (commit-before-flush) and is merged here:

  • https://github.com/abpframework/abp/pull/26017 (validated)

  If you can, the most definitive mitigation is:

  1. Upgrade ABP to a version that includes that PR (post-10.5.0, per the linked support thread).
  2. After upgrade, remove any custom workaround you add for commit timing.

  If you cannot upgrade immediately, the practical workaround pattern (already validated in ABP support) is to force the relevant OpenIddict work to be committed inside a new UnitOfWork earlier in the OpenIddict event pipeline (so the DB state is consistent/visible before other concurrent operations proceed). The support ticket shows this pattern for identity sessions; you can apply the same “commit now” idea to the part of the pipeline that creates/updates tokens in your scenario.

  A second (often necessary) mitigation is at the client/API gateway level:

  • Ensure your clients never send parallel refresh-token requests using the same refresh token (serialize refresh calls per user/session), because refresh token rotation + parallel refresh is the canonical way to produce token-store concurrency conflicts.

  2) Should AbpOpenIddictTokenStore.UpdateAsync/CreateAsync translate to OpenIddictExceptions.ConcurrencyException?

  Yes: OpenIddict’s server pipeline expects concurrency failures from the store to be surfaced as OpenIddictExceptions.ConcurrencyException so it can translate them into protocol-appropriate responses (typically invalid_grant for refresh flows). If ABP lets AbpDbConcurrencyException escape, it will be logged as an infrastructure error and can leak as 500/unhandled depending on where it’s caught.

  I couldn’t verify the exact AbpOpenIddictTokenStore implementation in source because the code-search tool backend was unavailable in this environment, so I can’t point to the exact catch/translate location in ABP 10.4.1. However, based on the observed behavior and OpenIddict conventions, this translation is the correct behavior and aligns with how OpenIddict stores are expected to report concurrency issues.

  3) Could cleanup worker / refresh-token reuse explain hourly fixed pattern? Which options control them?

  The fixed minute marks strongly suggest a scheduled/non-human client (mobile app token refresh loop, kiosk, integration service, health-check identity probe, etc.) rather than ABP’s own token pruning:

  • OpenIddict’s built-in pruning typically runs on an interval, but your timestamps repeating at very specific offsets each hour is more characteristic of one or more clients refreshing tokens on a schedule.
  • The SQL you captured (UPDATE ... WHERE AuthorizationId = @id) matches a “revoke tokens by authorization” style operation, which is commonly triggered by refresh token rotation/reuse detection or authorization revocation flows.

  What to do operationally:

  1. Correlate the errors with client_id / subject / authorization_id involved at those times (enable higher OpenIddict/EF logging around failures).
  2. Identify the scheduled actor (job, integration, device fleet).
  3. Enforce single-flight refresh per subject/client (mutex in client; or server-side distributed lock keyed by (client_id, subject) for refresh endpoint).

  ---

  Sources

  • https://abp.io/support/questions/10853 (validated)
  • https://github.com/abpframework/abp/pull/26017 (validated)
  • https://abp.io/docs/latest/framework/architecture/domain-driven-design/unit-of-work (validated)
  • https://abp.io/docs/10.0/release-info/migration-guides/abp-10-0 (validated)

  ---

  This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  mohmmd.khalaf@gmail.com created 18 hours ago

  Thanks. To confirm: PR 26017 / thread 10853 concern AbpSessions, not OpenIddictTokens. Could you confirm whether the change affects AbpOpenIddictTokenStore at all?

  The remaining question is the one you could not verify. Does AbpOpenIddictTokenStore.UpdateAsync/CreateAsync catch AbpDbConcurrencyException and rethrow OpenIddictExceptions.ConcurrencyException in 10.4.1 or in any later version? If not, can this be treated as a bug and tracked in the ABP repo?

  We will add single-flight refresh on the client side and log client_id / authorization_id at the failure points, then report back.

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  maliming created 17 hours ago

  Support Team Fullstack Developer

  Hi,

  ABP 10.4.1 has a bug here. When a token is created or updated, ABP also updates the ConcurrencyStamp of the related OpenIddictAuthorization if it's loaded in the same DbContext. So concurrent token requests under the same authorization can conflict and throw AbpDbConcurrencyException.

  It's fixed in 10.6.0: https://github.com/abpframework/abp/pull/25824

  For 10.4.1, you can add the same change to ConfigureServices of the module of your app that handles /connect/token:

  using Volo.Abp.Domain.Entities.Events;
  using Volo.Abp.OpenIddict.Authorizations;
  
  Configure<AbpEntityChangeOptions>(options =>
  {
      options.IgnoredNavigationEntitySelectors.Add("DisableOpenIddictAuthorization", type => type == typeof(OpenIddictAuthorization));
  });
  

  You can remove it after upgrading to 10.6.0 or later.

  AbpOpenIddictTokenStore.UpdateAsync already converts the exception to OpenIddictExceptions.ConcurrencyException, but it logs the original error first. So if two requests really update the same token at the same time, you'll still see this error in the logs. That's expected.

  If you still get unhandled exceptions after this change, please share the full exception and the request path of one of them.

  Thanks

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel