Activities of "DominaTang"

We rolled back our QA site from ABP 9 to ABP8:

1. Restore database backup prier to ABP 9 upgrade
2. Deploy code back to ABP 8.2.3 version

However, when login page, it keeps giving us 500 error in login page, from exception below, obviously in ABP 9 these columns are dropped, but ABP 8 table has it. We check the code deployed to app container, the ABP version is 8.2.3. We delete the redis cache pod, and create a new one, the error is still there.

[17:21:29 ERR] An unhandled exception has occurred while executing the request. Microsoft.Data.SqlClient.SqlException (0x80131904): Invalid column name 'IsDeleted'. Invalid column name 'CreationTime'. Invalid column name 'CreatorId'. Invalid column name 'DeleterId'. Invalid column name 'DeletionTime'. Invalid column name 'IsDeleted'. Invalid column name 'LastModificationTime'. Invalid column name 'LastModifierId'. at Microsoft.Data.SqlClient.SqlCommand.<>c.<ExecuteDbDataReaderAsync>b__195_0(Task1 result) at System.Threading.Tasks.ContinuationResultTaskFromResultTask2.InnerInvoke() at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state) --- End of stack trace from previous location --- at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot, Thread threadPoolThread) --- End of stack trace from previous location --- at Microsoft.EntityFrameworkCore.Storage.RelationalCommand.ExecuteReaderAsync(RelationalCommandParameterObject parameterObject, CancellationToken cancellationToken) at Microsoft.EntityFrameworkCore.Storage.RelationalCommand.ExecuteReaderAsync(RelationalCommandParameterObject parameterObject, CancellationToken cancellationToken) at Microsoft.EntityFrameworkCore.Query.Internal.SplitQueryingEnumerable1.AsyncEnumerator.InitializeReaderAsync(AsyncEnumerator enumerator, CancellationToken cancellationToken) at Microsoft.EntityFrameworkCore.SqlServer.Storage.Internal.SqlServerExecutionStrategy.ExecuteAsync[TState,TResult](TState state, Func4 operation, Func4 verifySucceeded, CancellationToken cancellationToken) at Microsoft.EntityFrameworkCore.Query.Internal.SplitQueryingEnumerable1.AsyncEnumerator.MoveNextAsync() at Microsoft.EntityFrameworkCore.EntityFrameworkQueryableExtensions.ToListAsync[TSource](IQueryable1 source, CancellationToken cancellationToken) at Microsoft.EntityFrameworkCore.EntityFrameworkQueryableExtensions.ToListAsync[TSource](IQueryable1 source, CancellationToken cancellationToken) at Volo.Abp.OpenIddict.Authorizations.EfCoreOpenIddictAuthorizationRepository.FindAsync(String subject, Guid client, String status, String type, CancellationToken cancellationToken)

I noticed ABP has these code:

context.Services .AddDataProtection() .SetApplicationName("MyApp") .PersistKeysToStackExchangeRedis(redis, "MyApp-Protection-Keys");

However, if our application want to use Microsoft Data Protection API to encyrpt/decrypt business data, we have this settings: services.AddDataProtection() .ProtectKeysWithAzureKeyVault(new Uri(keyId), new DefaultAzureCredential(new DefaultAzureCredentialOptions { ManagedIdentityClientId = keyVaultClientId })) .PersistKeysToAzureBlobStorage(azureStorageConnectionString, containerName, EncrptionConsts.DataProtectionKeyBlobName) .SetDefaultKeyLifetime(TimeSpan.FromDays(36500));

Would these two settings conflict with each other, can we simply comment out ABP's AddDataProtectioncode?

Thanks

[maliming] said: hi

Can you share your project source code?

I will download and check the code.

You can remove the environment code so I can reproduce it on my local.

liming.ma@volosoft.com

Thanks.

I heard another project in company using ABP 9 also met 409 error. It's bit hard to reproduce it at local. Occasionally it happens, but very easy to met 409 at QA site.

From exception log, it is OpenIddictAuthorizations table has concurrency issue. I replace above code MyAbpEfCoreNavigationHelper with it; After deployment, the URL bounce between home page and auth server several times, then successfully locate to home page. Then I try the login again, the app throw 400 error instead of the 409

Or is there a way in auth server we create some controller method, which Url could match connect/authorize and the code call base.authorize and try catch 409 to swallow this error

I tested with QA team against our QA site, we noticed when we click submit security code at the same time, it's much easy to reproduce. This issue becomes our upgrade blocker. Could we have a session to debug?

Even a success login, the home search page flash 2+ times, looks like go to auth server again and back to home page

After upgrade to 9.1.3, the error is still there. It happens when make connect/authorize Url, I did Url decoding and Html decoding to the Url, it looks like this, I feel like the Url is extremely long and duplicate connect https://ca.authserver.host/connect/authorize?response_type=code&client_id=Angular&state=azU5cEs1Sk9Ua2JTcm1aVHlzaExiWjZrQXpqNUhxUVNNQUpsNDc1NXlKN2VR;/home/es-search?code=FbCK06zR-ZE3xt7LplqKFuOFVxuwjbgnqJobXC4z2v4&state=QVViSjhnd1VGWGFGQ3JjRFo3aExxTEZfdjNhR1VkTGp6MzBnYjhacTV3Rmp6;%252Fhome%252Fsearch%253Fcode%253DfVFNO5CT4ozUXn3SWbWF3Yx_vRmv8z8g9luGtz-jOCM%2526state%253DMzY3N2ZRV2F3UGNtNTlkbXQ1NWtyNUtTeXFKMlRpRXV1b1dWd3djWUwxdzdK%253B%2525252Fhome%2525252Fes-search%2526iss%253Dhttps%253A%25252F%25252Fca.authserver.host%25252F%2526culture%253Den%2526ui-culture%253Den&iss=https:%2F%2Fca.authserver.host%2F&culture=en&ui-culture=en&redirect_uri=https://ca.ess-portal.host/&scope=offline_accessopenidprofileemailphoneAccountServiceIdentityServiceAdministrationServiceSaasServiceEntityServiceSearchServiceLookupServiceAuditServiceDashboardService&code_challenge=cl1auIiaHiVaQMiBpDPk2OMIAccR0P9wJa2mOZMdG5w&code_challenge_method=S256&nonce=azU5cEs1Sk9Ua2JTcm1aVHlzaExiWjZrQXpqNUhxUVNNQUpsNDc1NXlKN2VR&culture=en&ui-culture=en&returnUrl=/home/search?code=FbCK06zR-ZE3xt7LplqKFuOFVxuwjbgnqJobXC4z2v4&state=QVViSjhnd1VGWGFGQ3JjRFo3aExxTEZfdjNhR1VkTGp6MzBnYjhacTV3Rmp6;%2Fhome%2Fes-search%3Fcode%3DfVFNO5CT4ozUXn3SWbWF3Yx_vRmv8z8g9luGtz-jOCM%26state%3DMzY3N2ZRV2F3UGNtNTlkbXQ1NWtyNUtTeXFKMlRpRXV1b1dWd3djWUwxdzdK%3B%25252Fhome%25252Fes-search%26iss%3Dhttps%3A%252F%252Fca.authserver.host%252F%26culture%3Den%26ui-culture%3Den&iss=https://ca.authserver.host/&culture=en&ui-culture=en

I upgrade the front-end code to exactly version of '9.1.3', I also update backend to 9.1.3. The 409 still happens. Is there a way to swallow this 409 error either from front-end or backend?

The code use to use '~9.1.1', if I check the lock file, it does install 9.1.3. If I use exact version 9.1.1 or 9.1.2, it will have null DI exception. Now I change to use exact version '9.1.3' the DI exception is gone.

However, the console error in the beginning of this ticket is still there.