Activities of "maliming"

hi

The MobileNavbar component was moved from the SideMenu namespace to the Common namespace starting from LeptonX 4.3 (ABP 9.3). Since you are upgrading directly from ABP 8 to ABP 10, you hit this breaking change.

To fix the compile error, update the @using directive in your customized Default.cshtml:

Old (ABP 8 / LeptonX 3.x):

@using Volo.Abp.AspNetCore.Mvc.UI.Theme.LeptonX.Themes.LeptonX.Components.SideMenu.MobileNavbar

New (ABP 10 / LeptonX 5.x):

@using Volo.Abp.AspNetCore.Mvc.UI.Theme.LeptonX.Themes.LeptonX.Components.Common.MobileNavbar

The @model MobileNavbarViewModel declaration itself is still valid — only the namespace changed.

Note that the Default.cshtml template also has significant HTML structure changes between LeptonX 3.x and 5.x (the layout of the mobile nav tabs was redesigned), and the MainMenuViewComponent reference was replaced with MobileMainMenuViewComponent. If you are getting layout issues after fixing the compile error, you may need to compare your customized file against the latest LeptonX source and update the HTML structure accordingly.

Thanks

hi

Thanks for the detailed report. Let me address each issue separately.

AutoMapper 13.0.1 (GHSA-rvv3-g6hj-g44x)

The ABP team has applied a code-level mitigation for this vulnerability in PR #25138 by setting MaxDepth = 64 for all AutoMapper maps that don't have an explicit MaxDepth configured. However, this fix is going into the upcoming ABP release and will not be backported to 8.2.3.

Since you're staying on ABP 8.2.3 / .NET 8, you can apply the same mitigation manually in your own project. Additionally, since the AutoMapper maintainer has confirmed no patch will be released for the affected version, your NuGet security audit will continue showing NU1902/NU1903 warnings regardless. To suppress the warning, add the following to your Directory.Build.props (or individual .csproj files):

<ItemGroup>
  <NuGetAuditSuppress Include="https://github.com/advisories/GHSA-rvv3-g6hj-g44x" />
</ItemGroup>

If you hold a commercial AutoMapper license (LuckyPenny Software), you can override the AutoMapper package to version 15.1.1 in your projects. The ABP team has also released a Volo.Abp.LuckyPenny.AutoMapper integration package (see #25153) as a drop-in replacement for Volo.Abp.AutoMapper for users with such a license — though note this targets newer ABP versions, so you would need to adapt it manually for 8.2.3.

As a long-term solution, we recommend migrating from AutoMapper to Mapperly, which ABP Framework has built-in support for. See the migration guide for details.

Select2 4.0.13

Select2 4.0.13 is actually the latest stable release in the 4.0.x series (released January 28, 2025). The only known vulnerability in Select2 (GHSA-rf66-hmqf-q3fc) was fixed in version 4.0.6 — 4.0.13 is well past that threshold and is not affected. The scanner result is a false positive, and I'd recommend raising it with your security scanning tool vendor.

Additionally, since your UI type is React, Select2 is only present in the MVC-based Auth Server pages, not your main React frontend, so the actual exposure is further limited.

Thanks

Hi,

Thanks for the detailed report. Before suggesting a fix, could you share the output of:

npm list @abp/ng.core

The reason is: the error "No provider found for RestService" is unusual — in newer ABP versions RestService is providedIn: 'root' and should always be resolvable. If you're on an older ABP version (built for Angular 17), the compiled package may not be compatible with Angular 20's DI runtime, which would explain why the provider registration silently fails.

In the meantime, there's one thing in your AppModule that should be fixed regardless:

@NgModule({
  imports: [
    AbpModule,
    BrowserModule,
    BrowserAnimationsModule,
    AppRoutingModule,
    // HttpClientModule,  ← remove this
  ],
})
export class AppModule {}

HttpClientModule (old API) should be removed. ABP's CoreModule.forRoot() already sets up HttpClient internally via provideHttpClient(). Having both at the same time can cause provider conflicts in Angular 20.

However, if the error persists after removing HttpClientModule, the most likely root cause is that your @abp/ng.* packages were compiled for Angular 17 and are not compatible with Angular 20. In that case, upgrading all @abp/ng.* packages to a version that officially supports Angular 20 would be the required fix.

To answer your questions directly:

• No, you don't need to migrate to standalone APIs — NgModule-based architecture is still fully supported.
• No, the AbpModule wrapper pattern is not the problem.

Please share your ABP package version and we can give you more targeted guidance.

Thanks

Hi,

You can use the ABP CLI to upgrade all ABP-related packages in your solution.

First, make sure you have the latest ABP CLI:

dotnet tool update -g Volo.Abp.Cli

Then navigate to your solution root folder and run:

abp update

This command will automatically update all ABP NuGet packages across the solution. If you also want to update NPM packages, add the --npm flag:

abp update --npm

If you want to upgrade to a specific version, use:

abp update --version <target-version>

After upgrading, please check the migration guide for any breaking changes or required manual steps for your target version.

Thanks

hi

Is this the live website after deployment, or still the development environment?

Have you enabled Redis?

Can you share the debug logs.txt of the slow/all requests?

https://abp.io/support/questions/8622/How-to-enable-Debug-logs-for-troubleshoot-problems

liming.ma@volosoft.com

Thanks.

Hi,

The console errors you're seeing are not the root cause of your offline loading issue:

• The source map warnings (.map files returning 404) are harmless — they are only used for debugging in DevTools and have no effect on app behavior.
• The MONO_WASM: WebAssembly.Compile is disallowed on the main thread warning is a Chrome browser limitation for synchronous WASM compilation. The runtime falls back to interpreted mode for that method and the app should still continue running.

These warnings likely appear in online mode too, but you didn't notice because everything worked fine.

To help diagnose the actual offline loading problem, could you provide more details?

1. When the app fails to load offline, what exactly happens — is it a blank/white screen, a loading spinner that never finishes, or does it show a specific error page?
2. By "offline", do you mean the device has no internet at all, or that it's running on a local network without public internet access?
3. Is your authentication server (OpenIddict) hosted on the same local network and accessible from the client device without internet?
4. Could you share the exact steps to reproduce this issue using a freshly created ABP Studio Blazor WebAssembly project? This will help us isolate whether it's a template issue or something specific to your setup.

Thanks

hi

We've gone through your module code carefully and everything looks correct — the CMS Kit public APIs don't have any authorization restrictions, the GlobalFeature configuration follows the standard template pattern, and the middleware setup looks fine. We can't spot any code-level issue that would cause the 302 redirect.

To move forward, we need a bit more information:

1. Debug logs — Please enable Debug-level logging following this guide: https://abp.io/support/questions/8622/How-to-enable-Debug-logs-for-troubleshoot-problems, reproduce the issue, and share the logs. The logs should tell us exactly what exception is being thrown and why the redirect is triggered.

2. Try publishing locally — Could you publish the public website to your local machine (or a staging environment) with the same production configuration? This would help us confirm whether the issue is specific to your production server/environment rather than the application code itself.

3. Minimal reproduction — If possible, could you create a fresh ABP project with the same setup and see if the issue reproduces? This would help us isolate whether it's something unique to your codebase or a more general configuration problem.

Thanks

Hi,

A few more things that would help us pinpoint the exact cause:

1. Local anonymous test — Could you open an incognito/private browser window (completely logged out) and try accessing your local public website? Check if the menus and home page are visible. This is important because the issue might actually also exist locally but was never tested anonymously.

2. Production logs — Please enable Debug-level logging by following this guide: https://abp.io/support/questions/8622/How-to-enable-Debug-logs-for-troubleshoot-problems

   Then reproduce the issue and share the logs.txt. We're looking for Warning entries around the time the anonymous request hits /api/cms-kit-public/menu-items — the log message will contain the exact feature name that failed, which will tell us the root cause directly.

3. More code — Could you also share the full TriArchPublicModule class, including the [DependsOn] attributes and the complete PreConfigureServices method? Also, a quick search in your public website project for any usage of GlobalFeatureManager would be helpful.

Thanks

Hi,

ABP's default background job system (Volo.Abp.BackgroundJobs) does not expose the current retry count directly inside the job handler. The TryCount is tracked in BackgroundJobInfo, but the JobExecutionContext passed to your job only contains ServiceProvider, JobType, JobArgs, and CancellationToken — not the BackgroundJobInfo itself.

For your use case (move failed jobs to a custom table after 10 retries), you can override BackgroundJobWorker and customize two virtual methods:

• CalculateNextTryTime — override this to return null when jobInfo.TryCount reaches your limit, which causes ABP to mark the job as abandoned
• TryUpdateAsync — override this to detect when jobInfo.IsAbandoned is true and insert the job into your custom table at that point

Note that TryUpdateAsync doesn't have a scoped service provider parameter, so you should use the inherited ServiceScopeFactory to create a scope when resolving your repository.

Finally, replace the default registration in your module's ConfigureServices:

context.Services.Replace(ServiceDescriptor.Singleton<IBackgroundJobWorker, MyBackgroundJobWorker>());

Give it a try and let us know if you run into any issues!

Thanks

hi

Can you share a demo app?

I will check it in offline mode.

liming.ma@volosoft.com

Thanks.