Fix crash on startup when the database contains no game configuration

[sven-n]

Fixes #908.

When the database schema exists but the GameConfiguration is missing (e.g. after a failed import), the Startup project crashed while building the host.

Root causes

• Program.CreateHostAsync: the ByDataSourceReferenceHandler factory dereferenced the default game configuration id (configId!.Value) without a null check → NullReferenceException. It's resolved while constructing the PlugInManager singleton, so the host never started.
• Program.CreateMissingPlugInConfigurations: context.GetAsync<GameConfiguration>()...First() threw an InvalidOperationException, because PlugInConfigurationsFactory always tries to create the plugin configurations it finds missing — which is all of them on an empty database.

Changes

Startup

• Startup/Program.cs: both paths handle a missing game configuration now. The configuration context in the reference handler factory is disposed properly, too.
• Since the server can now boot into an uninitialized state, the PlugInManager singleton starts without plugin configurations. Program subscribes to SetupService.DatabaseInitialized (before the host, and with it the server containers, is started) and reads the created plugin configurations afterwards.
• The data source of the plugin manager's reference handler is reloaded at that point. Otherwise the references within the custom plugin configurations would be resolved on a data source which is either not loaded at all (empty database) or holds the previous, deleted game configuration (re-install). The configurations are taken from that reloaded data source, so they stay alive as long as the reference handler does, and the registered ICollection<PlugInConfiguration> is updated as well.

Plugin manager

• The configuration loop of the constructor moved into a public ReadConfigurations(IEnumerable<PlugInConfiguration>), which can be called again when the configurations become available later.
• Reading the configurations again can also activate a plugin now, which is required when it was inactive in the previously read data. Previously read configurations aren't observed anymore, so the PropertyChanged handlers don't pile up.
• A failing configuration doesn't stop the remaining ones from being read anymore.

Setup service and page

• SetupService.CreateDatabaseAsync awaits the subscribers of its DatabaseInitialized event one after another. A multicast delegate only returns the task of the last subscriber, so the plugin configurations were applied while the server containers were already restarting.
• The new DataInitializationState (Initialized, NotInitialized, Unknown) tells a failed or timed out check apart from an actually empty database. The setup page only offers the unconfirmed Create button for NotInitialized; Unknown keeps the confirmed ReInstall button.
• The page determines the state again after a schema update (it can't be determined on an outdated schema) and loads it before it hides the installer.

Testing

• Full solution builds without errors.
• MUnique.OpenMU.Tests (984), MUnique.OpenMU.Web.Tests (95), MUnique.OpenMU.PlugIns.Tests (41), MUnique.OpenMU.ChatServer.Tests (26) and MUnique.OpenMU.Persistence.Initialization.Tests (21, 6 skipped) pass.
• Not verified by an end-to-end startup against a real PostgreSQL instance - that wasn't available in the used environment.

---

Generated by Claude Code

[sven-n]

The startup fix works: an empty database no longer crashes the server. The follow-up after an install has problems, though:

• Plugin configurations fail after an install. PlugInManager keeps the reference handler it got at startup, whose data source never loaded a game configuration. The first custom configuration with a reference throws and stops the loop (see Program.cs:423).
• The new "Create" button wipes the database without asking. IsDataInitializedAsync returns false on a timeout or error, so a populated database can land on this branch (see Setup.razor:36).
• This handler doesn't finish before the servers restart. The multicast AsyncEventHandler only returns the last subscriber's task, so the handler races RestartAllAsync (see Program.cs:344).

The rest are smaller follow-ups and nits.

---

Generated by Claude Code

[cloudflare-workers-and-pages]

Deploying openmudocs with    Cloudflare Pages

Latest commit:	c807ca4
Status:	✅  Deploy successful!
Preview URL:	https://7e3ea4b6.openmudocs.pages.dev
Branch Preview URL:	https://claude-issue-908-vwkrug.openmudocs.pages.dev

View logs