Symptom
Launch VS Code with an issue preview tab left open from the previous session. The tab renders "The editor could not be opened due to an unexpected error. Please consult the log for more details." with a stack through resolveWebview → createModelReference → acquire. Clicking Try Again a moment later works.
Root cause (verified against the installed VS Code bundle and the extension source)
- At startup VS Code restores the saved editor, the built-in markdown preview (
vscode.markdown.preview.editor) on a codev-issue:<n>.md URI, before any extension has activated.
- The preview resolves its document through the text model service. With no content provider registered for the scheme, the resolver calls the file service's
activateProvider(scheme), which fires the onFileSystem:codev-issue activation event, waits for any extension that declares it, and retries once.
- Nothing declares that event. The extension's
activationEvents in apps/vscode/package.json are workspaceContains:.codev, workspaceContains:codev, and onStartupFinished, all of which fire later. The retry finds still no provider and throws Unable to resolve text model content for resource codev-issue:<n>.md; the webview resolver surfaces that as the generic error pane.
- The extension then activates normally and registers the provider (
apps/vscode/src/commands/view-issue.ts:247), which is why Try Again succeeds.
This is one step earlier than the #1592 recovery fix. That fix handles a registered provider with no content yet (the "Content unavailable" fallback now self-heals once Tower connects). Here the provider does not exist at restore time at all.
Fix
Declare onFileSystem:codev-issue in activationEvents. VS Code's resolver then activates the extension on exactly that event, the provider registers before the retry, and the #1592 recovery path fills the content once Tower connects. The provider registration in activate() already runs before the extension awaits Tower initialisation, so no reordering is needed.
Apply the same declaration to the other content-provider scheme the extension restores into editors: codev-diff (apps/vscode/src/commands/view-diff.ts:192), which backs the builder file diffs and the multi-file review editor. Any future registerTextDocumentContentProvider scheme needs the matching onFileSystem: entry; a parity test over package.json against the registered schemes would keep them in step, in the style of the existing contributes parity tests.
Verification
Open an issue preview and a builder diff, quit VS Code, relaunch: both tabs render without the error pane, the preview shows the fallback until Tower connects and then fills. Try Again is never needed.
Relation
Symptom
Launch VS Code with an issue preview tab left open from the previous session. The tab renders "The editor could not be opened due to an unexpected error. Please consult the log for more details." with a stack through
resolveWebview→createModelReference→acquire. Clicking Try Again a moment later works.Root cause (verified against the installed VS Code bundle and the extension source)
vscode.markdown.preview.editor) on acodev-issue:<n>.mdURI, before any extension has activated.activateProvider(scheme), which fires theonFileSystem:codev-issueactivation event, waits for any extension that declares it, and retries once.activationEventsinapps/vscode/package.jsonareworkspaceContains:.codev,workspaceContains:codev, andonStartupFinished, all of which fire later. The retry finds still no provider and throwsUnable to resolve text model content for resource codev-issue:<n>.md; the webview resolver surfaces that as the generic error pane.apps/vscode/src/commands/view-issue.ts:247), which is why Try Again succeeds.This is one step earlier than the #1592 recovery fix. That fix handles a registered provider with no content yet (the "Content unavailable" fallback now self-heals once Tower connects). Here the provider does not exist at restore time at all.
Fix
Declare
onFileSystem:codev-issueinactivationEvents. VS Code's resolver then activates the extension on exactly that event, the provider registers before the retry, and the #1592 recovery path fills the content once Tower connects. The provider registration inactivate()already runs before the extension awaits Tower initialisation, so no reordering is needed.Apply the same declaration to the other content-provider scheme the extension restores into editors:
codev-diff(apps/vscode/src/commands/view-diff.ts:192), which backs the builder file diffs and the multi-file review editor. Any futureregisterTextDocumentContentProviderscheme needs the matchingonFileSystem:entry; a parity test overpackage.jsonagainst the registered schemes would keep them in step, in the style of the existing contributes parity tests.Verification
Open an issue preview and a builder diff, quit VS Code, relaunch: both tabs render without the error pane, the preview shows the fallback until Tower connects and then fills. Try Again is never needed.
Relation