Activities of "maliming"

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.

hi

Can you share the full code of your public web module?

ConfigureAuthentication

Thanks.

Hi,

Thanks for the screenshot. Let me address the errors you're seeing:

Yellow warnings (non-critical): The three "DevTools failed to load source map" warnings (.map files returning 404) are harmless — these are only needed for debugging and don't affect your app's functionality.

Red error: The MONO_WASM: ParseAttributes:2e code generation failed: RangeError: WebAssembly.Compile is disallowed on the main thread, if the buffer size is larger than 4KB is a Chrome browser limitation. Chrome restricts synchronous WebAssembly compilation on the main thread for modules larger than 4KB. When this happens, the Mono runtime falls back to interpreted execution for that method, which is usually non-fatal — the app should still work, just slightly slower for that code path.

Could you provide a bit more context?

1. What version of .NET / ABP are you using?
2. Does the app load correctly when online? Or does it fail in both online and offline modes?
3. Are you seeing a blank/stuck loading screen, or does it actually crash with an error?
4. Can you try it in the latest Chrome browser?

If the app works online but fails only when offline, the issue is likely related to the service worker not caching all required Blazor assets properly. In that case, try clearing the browser cache and service worker registration (DevTools → Application → Storage → Clear site data), then reload online first to let the service worker re-cache everything.

Thanks

hi

Request sent You’ll get an email letting you know if your request was approved

Thanks.