Conversation
feat: Added Platform Startup Extension Point that allows modules to participate in platform startup phases before the normal IModule lifecycle begins.
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
| foreach (var manifestFile in Directory.EnumerateFiles(discoveryPath, "module.manifest", SearchOption.AllDirectories)) | ||
| { | ||
| // Exclude manifests from built modules artifacts | ||
| if (manifestFile.Contains("artifacts")) |
There was a problem hiding this comment.
Artifacts path filter checks full path, not relative
Medium Severity
The manifestFile.Contains("artifacts") check tests the entire absolute path, unlike the equivalent code in LocalStorageModuleCatalog.cs which uses manifestFile.Substring(_discoveryPath.Length).Contains("artifacts") to only check the relative portion after the discovery path. If the discovery path itself contains "artifacts" (common in CI/CD pipelines, e.g. /build/artifacts/modules/), every manifest will be skipped and no IPlatformStartup types will be discovered.
| { | ||
| //Conditionally use the hangFire server for this app instance to have possibility to disable processing background jobs | ||
| if (hostingContext.Configuration.GetValue("VirtoCommerce:Hangfire:UseHangfireServer", true)) | ||
| var configuration = configurationBuilder.Build(); |
There was a problem hiding this comment.
Unused configuration built inside ConfigureAppConfiguration callback
Low Severity
var configuration = configurationBuilder.Build() creates a configuration snapshot that is never used — the variable immediately goes out of scope. This appears to be a leftover from the removed Azure App Configuration logic. The Build() call is also wasteful since the framework will build the configuration itself after the callback returns.
|
|
❌ The last analysis has failed. |
1 participant
Description
feat: Added Platform Startup Extension Point that allows modules to participate in platform startup phases before the normal IModule lifecycle begins.
References
QA-test:
Jira-link:
https://virtocommerce.atlassian.net/browse/VCST-4696
Artifact URL:
Note
Medium Risk
Touches platform bootstrapping (Program/Startup) and adds early assembly loading/resolution for module-provided startup hooks, so misconfiguration or ordering issues could affect app startup. Azure App Configuration is no longer wired directly in the web host and must be provided via the new startup hook if needed.
Overview
Introduces a new module extension point,
IPlatformStartup, allowing modules to hook into host configuration, host-level service registration, app service registration, and middleware setup across three pipeline phases (EarlyMiddleware,Initialization,LateMiddleware) with explicit priority ordering.Adds
startupTypetomodule.manifestand aPlatformStartupDiscoveryutility that scans manifests, loads module assemblies from the probing path, and instantiates startup types early inProgram.cs, then invokes their hooks fromProgram.csandStartup.Removes the platform’s direct Azure App Configuration integration (package reference and
Use/AddAzureAppConfigurationwiring) in favor of module-provided startup implementations, and bumpscoverlet.collectorto8.0.0across test projects.Written by Cursor Bugbot for commit ba30e59. This will update automatically on new commits. Configure here.
Image tag:
ghcr.io/VirtoCommerce/platform:3.1008.0-pr-2985-ba30-vcst-4696-ba30e598