Recover cleanly when a collection fails to open (BL-16678)

[StephenMcConnel]

After one collection fails to open, every later collection in the same run used to die with An item with the same key has already been added. Key: audio/startrecord. ProjectContext registers its ~65 project-level API endpoints on the application-level BloomServer.ApiHandler, so a project that failed part way through construction left them registered, and the next project's identical registrations hit a duplicate key.

#8204 (BL-16679) already fixes the reported symptom

It made the constructor dispose itself on failure, and Dispose already called ClearProjectLevelHandlers(). _scope is assigned well before the first RegisterWithApiHandler, so the clear is reached on the reported path. The log attached to the card confirms the boundary: the empty Bad Collection.bloomCollection failed at _scope.Resolve<CollectionSettings>(), before any registration, and poisoned nothing; the BL-16679 collection failed at _scope.Resolve<TeamCollectionApi>(), after, and poisoned everything.

So this PR is the hardening: recovery no longer depends on Dispose getting far enough, and it closes two other ways a failed open left Bloom running with no window and no way to quit.

1. The application-level reset can no longer be skipped

Dispose did the reset inside a try whose first statement was _scope.Resolve<BloomServer>() and whose catch only tolerated ObjectDisposedException. If that resolve threw anything else, ClearProjectLevelHandlers() was skipped, the exception was swallowed by the constructor's inner catch, and the next collection was poisoned again.

The server is now kept in a field, and the reset — extracted as ReleaseApplicationLevelProjectState — runs from that field, before anything that touches _scope.

We deliberately do not clear the server's own CurrentCollectionSettings. BloomServer reads it unguarded (e.g. to serve writingSystemDisplayForUI.css and files relative to the collection folder), so between one project closing and the next opening — exactly when the Open/Create Collections dialog is up — settings describing the collection we just left are a better answer than null. The next project overwrites them.

2. A clean slate is guaranteed at the recovery point

Program.HandleErrorOpeningProjectWindow is the one place that knows we failed and are about to offer another collection, so it repeats the reset (idempotent), with a Debug.Assert that Dispose should already have done it.

Its reporting half is now separate and guarded. It runs inside OpenProjectWindow's catch, and the callers depend on OpenProjectWindow returning false to put up the chooser — so a failure to report used to take the user's way back into the app with it.

3. One throw no longer wedges startup permanently

StartupScreenManager.DoStartupAction ran _current.Task() unguarded, and returns immediately on every later idle while _current is set. A throw therefore killed the queue for the rest of the run: the splash screen never closed, ChooseACollection() never ran, nothing called ProgramExit.Exit() so not even its 20-second force-quit net was armed, and Main's finally never released the UniqueToken — so the next launch was turned away with "Bloom is already running". That is the shape the card's title describes.

FatalExceptionHandler cannot save this: during collection open UseFallback is true, so it shows a message and returns, letting the process carry on windowless.

4. ReopenProject gets the fallback its sibling already had

ReopenProject called OpenCollection(MruProjects.Latest) with nothing on failure, unlike OpenCollectionChosenInDialog — although it also runs with the Shell already closed (it is reached from a UI language change and from the Collection Settings dialog). New ChooseACollectionOrQuit is used at all three recovery sites, so a chooser that itself fails quits rather than idling invisibly.

5. Two diagnosis traps, and a null hole

• catch (FileNotFoundException) showed the "Bloom was not able to find all its bits" message, called ProgramExit.Exit(), then fell through into code dereferencing the _scope it had just failed to build — so what the user and Sentry actually saw was a NullReferenceException naming nothing useful.
• catch (Exception) { return; } inside the BeginLifetimeScope lambda would have abandoned every remaining registration, turning any failure there into an unrelated Autofac ComponentNotRegisteredException.
• The startup MRU pruning loop called IsInvalidCollectionToEdit(path) after path could have become null.

Testing

New BloomApiHandlerTests (5 tests) covers the application-level/project-level split the whole recovery depends on, and nothing covered it before. It includes a sanity check that re-registering without the clear really does throw the card's ArgumentException, so it cannot pass falsely. New StartupScreenManagerTests (3) covers a throwing startup action not wedging the queue. ProjectContextTests gains 3 tests for the new reset.

Full C# suite green (3155 passed). No TypeScript in the diff, so the front-end suite was not run.

Also verified by hand in the running app: with a deliberate failure staged just after audio/startRecord is registered, the card's repro now recovers — error dialog, chooser, and the good collection opens — and no windowless Bloom is left behind. With the self-dispose disabled to simulate the pre-#8204 state, Bloom did not survive at all, consistent with the card's reports.

Deliberately not done

• The MRU never demotes a collection that failed to open, so every launch retries it, reports, and offers the chooser. Leaving it: MostRecentPathsList.Paths already prunes on serialization and AddNewPath refuses to re-add, so demoting on one failure would drop a user's Team Collection from the Open/Create dialog after a transient network blip. Annoying but always recoverable beats silently losing a collection.
• Program.cs writes a double-clicked .bloomCollection to the MRU before trying to open it.
• CollectionSettings.DoDefenderFolderProtectionCheck calls Environment.Exit(-1) from inside the CollectionSettings constructor, skipping ReleaseBloomToken() — a read-only collection folder is currently unrecoverable, and the Defender-specific wording will mislead. Worth its own card.
• No --no-collection / Shift-at-startup escape hatch for a poisoned MRU.
• FileSystemWatcher.EnableRaisingEvents is called unguarded in TeamCollection.StartMonitoring and FolderTeamCollection, and nothing subscribes to FileSystemWatcher.Error.

Ref: https://issues.bloomlibrary.org/youtrack/issue/BL-16678

Devin review

---

This change is 

[greptile-apps]

Your trial has ended. Reactivate Greptile to resume code reviews.

[greptile-apps]

Your trial has ended. Reactivate Greptile to resume code reviews.

[StephenMcConnel]

[Claude Opus 5 (1M context) from Steve McConnel's machine during preflight] Consulted Devin on 2026-08-20 20:49 UTC, up to commit e5f662dcb161917bbc99241b3d3a4434dd85125d.

It raised one Bug and six Flags.

The Bug — the "path too long" signal being swallowed on the startup recovery path, leaving Bloom invisible — Devin itself now marks resolved. The local review had found the same thing independently, and it was fixed in e5f662dcb before Devin's pass finished, so there was never a thread to close.

Of the Flags, one needed investigating (the broken-install path now showing two dialogs) and is posted above as a review thread. It is deliberately left open: it is a user-facing judgement call that has gone to the developer as a decision rather than something to settle here.

The other five were informational and are not mirrored. All five are choices this PR makes deliberately and documents in code comments: a repeating startup action that throws is dropped rather than retried; the server's own copy of the collection settings is deliberately left alone; the collection lock is skipped when the settings file is absent; startup-task exceptions are reported rather than left fatal; and one ObjectDisposedException catch may now be unreachable, which is harmless.

CI is green. Greptile posted only a "trial has ended" notice, and CodeRabbit is switched off for this repo in .coderabbit.yml.

[greptile-apps]

Your trial has ended. Reactivate Greptile to resume code reviews.