Activities of "Baytech"

Hi, when will this be fixed? It is getting a little annoying that I have to add custom ABP code to fix ABP bugs whenever we upgrade our ABP version. Upgrading an ABP version and suddenly not being able to use Swagger is not ideal... feels like something that should have been caught before 9 went out.

hi Baytech

We will fix it in the next patch version. You can override the IdentitySessionManager to fix it. Thanks.

This fixes it. I don't like that solution though. Please fix it with a better solution in the next patch. Feels more like a band-aid solution than whatever the real fix is.

URGENT! Hi we upgraded to 9.0.0 and we are having issues logging out - one of the two revocat calls fails, leaving either the refresh or the access token alive, along with the application cookie. So when I log out, I just hit the login button and it auto logs me back in - no need for credentials. This is a GINORMOUS security concern. There is an error on the backend auth server every time this happens:

An unhandled exception has occurred while executing the request.
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.
 ---> Microsoft.EntityFrameworkCore.DbUpdateConcurrencyException: 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.
   at Npgsql.EntityFrameworkCore.PostgreSQL.Update.Internal.NpgsqlModificationCommandBatch.ThrowAggregateUpdateConcurrencyExceptionAsync(RelationalDataReader reader, Int32 commandIndex, Int32 expectedRowsAffected, Int32 rowsAffected, CancellationToken cancellationToken)
   at Npgsql.EntityFrameworkCore.PostgreSQL.Update.Internal.NpgsqlModificationCommandBatch.Consume(RelationalDataReader reader, Boolean async, CancellationToken cancellationToken)
   at Microsoft.EntityFrameworkCore.Update.ReaderModificationCommandBatch.ExecuteAsync(IRelationalConnection connection, CancellationToken cancellationToken)
   at Microsoft.EntityFrameworkCore.Update.ReaderModificationCommandBatch.ExecuteAsync(IRelationalConnection connection, CancellationToken cancellationToken)
   at Microsoft.EntityFrameworkCore.Update.Internal.BatchExecutor.ExecuteAsync(IEnumerable`1 commandBatches, IRelationalConnection connection, CancellationToken cancellationToken)
   at Microsoft.EntityFrameworkCore.Update.Internal.BatchExecutor.ExecuteAsync(IEnumerable`1 commandBatches, IRelationalConnection connection, CancellationToken cancellationToken)
   at Microsoft.EntityFrameworkCore.Update.Internal.BatchExecutor.ExecuteAsync(IEnumerable`1 commandBatches, IRelationalConnection connection, CancellationToken cancellationToken)
   at Microsoft.EntityFrameworkCore.Storage.RelationalDatabase.SaveChangesAsync(IList`1 entries, CancellationToken cancellationToken)
   at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.StateManager.SaveChangesAsync(IList`1 entriesToSave, CancellationToken cancellationToken)
   at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.StateManager.SaveChangesAsync(StateManager stateManager, Boolean acceptAllChangesOnSuccess, CancellationToken cancellationToken)
   at Npgsql.EntityFrameworkCore.PostgreSQL.Storage.Internal.NpgsqlExecutionStrategy.ExecuteAsync[TState,TResult](TState state, Func`4 operation, Func`4 verifySucceeded, CancellationToken cancellationToken)
   at Microsoft.EntityFrameworkCore.DbContext.SaveChangesAsync(Boolean acceptAllChangesOnSuccess, CancellationToken cancellationToken)
   at Volo.Abp.EntityFrameworkCore.AbpDbContext`1.SaveChangesAsync(Boolean acceptAllChangesOnSuccess, CancellationToken cancellationToken)
   --- End of inner exception stack trace ---
   at Volo.Abp.EntityFrameworkCore.AbpDbContext`1.SaveChangesAsync(Boolean acceptAllChangesOnSuccess, CancellationToken cancellationToken)
   at Volo.Abp.Uow.UnitOfWork.SaveChangesAsync(CancellationToken cancellationToken)
   at Volo.Abp.Uow.UnitOfWork.CompleteAsync(CancellationToken cancellationToken)
   at Volo.Abp.Uow.UnitOfWorkInterceptor.InterceptAsync(IAbpMethodInvocation invocation)
   at Volo.Abp.Castle.DynamicProxy.CastleAsyncAbpInterceptorAdapter`1.InterceptAsync(IInvocation invocation, IInvocationProceedInfo proceedInfo, Func`3 proceed)
   at Volo.Abp.Identity.IdentitySessionManager.RevokeAsync(IdentitySession session)
   at Volo.Abp.Identity.IdentitySessionManager.RevokeAsync(String sessionId)
   at Volo.Abp.Account.Web.Pages.Account.OpenIddictRevokeIdentitySessionOnRevocation.HandleAsync(HandleRevocationRequestContext context)
   at OpenIddict.Server.OpenIddictServerDispatcher.DispatchAsync[TContext](TContext context)
   at OpenIddict.Server.OpenIddictServerDispatcher.DispatchAsync[TContext](TContext context)
   at OpenIddict.Server.OpenIddictServerHandlers.Revocation.HandleRevocationRequest.HandleAsync(ProcessRequestContext context)
   at OpenIddict.Server.OpenIddictServerDispatcher.DispatchAsync[TContext](TContext context)
   at OpenIddict.Server.OpenIddictServerDispatcher.DispatchAsync[TContext](TContext context)
   at OpenIddict.Server.AspNetCore.OpenIddictServerAspNetCoreHandler.HandleRequestAsync()
   at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
   at Volo.Abp.AspNetCore.Security.AbpSecurityHeadersMiddleware.InvokeAsync(HttpContext context, RequestDelegate next)
   at Microsoft.AspNetCore.Builder.UseMiddlewareExtensions.InterfaceMiddlewareBinder.<>c__DisplayClass2_0.<<CreateMiddleware>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at Volo.Abp.Studio.Client.AspNetCore.AbpStudioMiddleware.InvokeAsync(HttpContext context, RequestDelegate next)
   at Volo.Abp.Studio.Client.AspNetCore.AbpStudioMiddleware.InvokeAsync(HttpContext context, RequestDelegate next)
   at Volo.Abp.Studio.Client.AspNetCore.AbpStudioMiddleware.InvokeAsync(HttpContext context, RequestDelegate next)
   at Microsoft.AspNetCore.Builder.UseMiddlewareExtensions.InterfaceMiddlewareBinder.<>c__DisplayClass2_0.<<CreateMiddleware>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at Volo.Abp.AspNetCore.Tracing.AbpCorrelationIdMiddleware.InvokeAsync(HttpContext context, RequestDelegate next)
   at Microsoft.AspNetCore.Builder.UseMiddlewareExtensions.InterfaceMiddlewareBinder.<>c__DisplayClass2_0.<<CreateMiddleware>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at Microsoft.AspNetCore.Localization.RequestLocalizationMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.RequestLocalization.AbpRequestLocalizationMiddleware.InvokeAsync(HttpContext context, RequestDelegate next)
   at Microsoft.AspNetCore.Builder.UseMiddlewareExtensions.InterfaceMiddlewareBinder.<>c__DisplayClass2_0.<<CreateMiddleware>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddlewareImpl.Invoke(HttpContext context)

Please fix this immediately. It does not happen in 8.

We are also experiencing the same issue. We were prompted today to login to nuget.abp.io

We enter the credentials, and when trying to run the application we receive an error to login: ABP-LIC-ERROR - License check failed for 'Volo.Payment.Domain-v5.1.3.0'. You need to log in using the command abp login <username>.

When we try to login with abp login: ABP CLI 9.0.0

  1. HTTP request attempt failed to https://abp.io/api/license/check-multiple-organizations? with an error: 403-Forbidden. Waiting 2 secs for the next try...

We have multiple abp commercial products with varying versions, all experiencing the same problem.

  • ABP Framework version: v8.3.0
  • UI Type: Angular
  • Database System: EF Core - PostgreSQL
  • Tiered (for MVC) or Auth Server Separated (for Angular): auth separated
  • Steps to reproduce the issue: Have 100k-200k entities, maybe 10 different entity types total. Call await _repo.InsertManyAsync(entities) for each entity type. It becomes very slow (30+ min) just on that InsertManyAsync call, not even saving changes yet. Bulk insert is not an option because it is paid, and EF should be able to handle that many easily - it is ABP that is slowing it down.

For what it's worth, I dug through ABP source code to find the culprit. It is on the PublishEntityCreatedEvent that gets called for every tracked entity in the AbpDbContext class. That eventually calls the AddOrReplaceEvent on the UnitOfWork class which does this: eventRecords.FindIndex(replacementSelector); where replacementSelector is defined as otherRecord => IsSameEntityEventRecord(eventRecord, otherRecord) in the EntityChangeEventHelper. That eventually gets to EntityHelper's EntityEquals(IEntity? entity1, IEntity? entity2) which uses a ton of reflection.

So for every new entity being tracked, it runs that equality reflection code for however many records have been inserted so far - the new tracked entity will never be in there, because it is new. So if I insert 200k entities, on the next entity added it runs through 200k entities to see if it needs to replace or add. The next entity after that it needs to do it 200,001 times. It gets exponentially slower, and it's very prohibitive. For what it's worth, I ended up fixing it by overriding the AbpDbContext and NOT publishing that tracked event for those entity types (ConnectWiseEntity is a base class I have for all 10 types) like so:

After that change, my bulk insert code went from 30-40 min to only 15 seconds.

I'd like to see 2 solutions here: make the local event publishing configurable like the distributed event publishing, AND fix the performance issue.

This is the code that does it in the EntityChangeEventHelper:

It runs the local event no matter what. Make that configurable like the distributed events below it.

I just made a brand new ABP project via the CLI on angular 18 and ABP 8.3.0, and it has the same issue.

Had to run yarn cache clean instead

The above steps did not work unfortunately, we're still left with the same warnings

  • ABP Framework version: v8.3.1
  • UI Type: Angular
  • Database System: EF Core Postgres
  • Tiered (for MVC) or Auth Server Separated (for Angular): Auth server separated
  • Exception message and full stack trace: NG0955 error
  • Steps to reproduce the issue: All we did was upgrade to latest of everything. Angular 18, ABP 8.3.1. Nowhere in our own code are we utilizing the new angular control flow stuff, and I see in the stack traces that it is coming from the leptonx theme code.

Seems like the errors are coming from leptonx theme related components. SubNavbarComponent specifically? In the stacktrace/minified code, it points here: volo-ngx-lepton-x.core.mjs

function SubNavbarComponent_ng_template_2_Conditional_6_Template(rf, ctx) {
  if (rf & 1) {
    i0.ɵɵelementStart(0, "ul", 11);
    i0.ɵɵrepeaterCreate(1, SubNavbarComponent_ng_template_2_Conditional_6_For_2_Template, 1, 1, "li", 12, _forTrack0, true);
    i0.ɵɵelementEnd();
  }
  if (rf & 2) {
    const ctx_r0 = i0.ɵɵnextContext(2);
    i0.ɵɵclassProp("collapsed", !ctx_r0.item.expanded);
    i0.ɵɵadvance();
    i0.ɵɵrepeater(ctx_r0.item.children);
  }
}

Here is our full package.json:

  "name": "BMK",
  "version": "0.0.0",
  "scripts": {
    "ng": "ng",
    "start": "ng serve --open",
    "build": "ng build",
    "build:prod": "ng build --configuration production",
    "watch": "ng build --watch --configuration development",
    "test": "ng test",
    "lint": "ng lint",
    "generate-proxy": "bash ./generateProxy.sh",
    "reset": "bash ./reset.sh"
  },
  "private": true,
  "dependencies": {
    "@abp/ng.components": "~8.3.1",
    "@abp/ng.core": "~8.3.1",
    "@abp/ng.oauth": "~8.3.1",
    "@abp/ng.setting-management": "~8.3.1",
    "@abp/ng.theme.shared": "~8.3.1",
    "@angular/animations": "~18.2.6",
    "@angular/common": "~18.2.6",
    "@angular/compiler": "~18.2.6",
    "@angular/core": "~18.2.6",
    "@angular/forms": "~18.2.6",
    "@angular/localize": "~18.2.6",
    "@angular/platform-browser": "~18.2.6",
    "@angular/platform-browser-dynamic": "~18.2.6",
    "@angular/router": "~18.2.6",
    "@volo/abp.commercial.ng.ui": "~8.3.1",
    "@volo/abp.ng.account": "~8.3.1",
    "@volo/abp.ng.audit-logging": "~8.3.1",
    "@volo/abp.ng.gdpr": "~8.3.1",
    "@volo/abp.ng.identity": "~8.3.1",
    "@volo/abp.ng.language-management": "~8.3.1",
    "@volo/abp.ng.openiddictpro": "~8.3.1",
    "@volo/abp.ng.text-template-management": "~8.3.1",
    "@volosoft/abp.ng.theme.lepton-x": "~3.3.1",
    "primeflex": "^3.3.1",
    "primeicons": "^7.0.0",
    "primeng": "16.3.1",
    "rxjs": "~7.8.0",
    "tslib": "^2.0.0",
    "zone.js": "~0.14.0"
  },
  "devDependencies": {
    "@abp/ng.schematics": "~8.3.1",
    "@angular-devkit/build-angular": "~18.2.6",
    "@angular-devkit/core": "~18.2.6",
    "@angular-devkit/schematics": "~18.2.6",
    "@angular-eslint/builder": "~18.3.1",
    "@angular-eslint/eslint-plugin": "~18.3.1",
    "@angular-eslint/eslint-plugin-template": "~18.3.1",
    "@angular-eslint/schematics": "~18.3.1",
    "@angular-eslint/template-parser": "~18.3.1",
    "@angular/cli": "~18.2.6",
    "@angular/compiler-cli": "~18.2.6",
    "@angular/language-service": "~18.2.6",
    "@types/jasmine": "~3.6.0",
    "@types/node": "^20.0.0",
    "@typescript-eslint/eslint-plugin": "8.7.0",
    "@typescript-eslint/parser": "8.7.0",
    "@typescript-eslint/utils": "8.7.0",
    "eslint": "^8.0.0",
    "jasmine-core": "~4.0.0",
    "karma": "~6.3.0",
    "karma-chrome-launcher": "~3.1.0",
    "karma-coverage": "~2.1.0",
    "karma-jasmine": "~4.0.0",
    "karma-jasmine-html-reporter": "^1.0.0",
    "typescript": "~5.5.0"
  }
}

We found it was because the email send type was changed to Queued, but we had disabled background jobs in our auth server. We had to manually add the line of code context.Services.Replace(ServiceDescriptor.Singleton<IBackgroundJobManager, NullBackgroundJobManager>()); even though the options had background jobs as disabled via Configure<AbpBackgroundJobOptions>(options => { options.IsJobExecutionEnabled = false; });. Feels like it should take that into account, instead of the literal implementation type of IBackgroundJobManager.

None that are different from the ABP 7 version, no. I got logs of both ABP 7 and ABP 8. 7 works, 8 doesn't - no obvious differences in the logs, no warnings/errors etc. nothing around that code has changed, the method still gets called with the same data.

Showing 1 to 10 of 34 entries
Made with ❤️ on ABP v9.1.0-preview. Updated on December 26, 2024, 06:07