Fix default view container not registered

[CGNonofr]

No description provided.

[nikolai-vysotskyi]

Thanks for picking this up so quickly! One concern about the control flow — as written I think it still falls through to the original crash in the case that actually bites a partial setup (no workbench.view.explorer registered at all, i.e. the #804 scenario):

const viewContainer = this.getViewContainer(key);
const container = viewContainer || this.getDefaultViewContainer();
if (!viewContainer) {
  collector.warn(/* "…added to 'Explorer'." */);
} else if (!container) {            // only reached when viewContainer is truthy → container === viewContainer → never falsy here
  collector.warn(/* "Default view container does not exist…" */);
  return;
}
// …proceeds to use `container`

When key's container is missing and there's no Explorer default, viewContainer is falsy → the first branch warns ("…added to 'Explorer'") but does not return, and container is undefined, so the downstream container.extensionId still throws. The else if (!container) branch is effectively dead — it only runs when viewContainer is truthy, in which case container === viewContainer is truthy too.

I think the !container guard needs to be independent of !viewContainer:

const viewContainer = this.getViewContainer(key);
const container = viewContainer || this.getDefaultViewContainer();
if (!container) {
  collector.warn(localize('DefaultViewContainerDoesnotExist', "Default view container does not exist and all views registered to '{0}' will not be added to the UI.", key));
  return;
}
if (!viewContainer) {
  collector.warn(localize('ViewContainerDoesnotExist', "View container '{0}' does not exist and all views registered to it will be added to 'Explorer'.", key));
}

Happy to verify your branch against our repro (Codex/Claude on a monaco partial setup with no Explorer registered) — that's exactly the no-default-container path. Once it covers that case I'll close #805 in favour of this. Thanks!

[CGNonofr]

Ok, I did it too fast!

[CGNonofr]

What about now?

[nikolai-vysotskyi]

To save a round-trip on why this slips through: stock code-server / VSCodium-web ship the real Explorer container, so getDefaultViewContainer() is defined there and missing-target views just land in Explorer — no crash. The crash only happens when both are missing (a partial monaco setup with no Explorer registered). Reduced to the control flow:

case	#806 as written	!container checked first
target missing, Explorer exists	OK (→ Explorer)	OK (→ Explorer)
target missing, no Explorer	container is undefined → still throws downstream	warn + return (skipped)

So the else if (!container) is unreachable as-is; moving the !container guard ahead of the !viewContainer check (with return) is what covers the no-Explorer path. Happy to confirm on our monaco repro (Codex/Claude, no Explorer) as soon as you push an update.

[CGNonofr]

Did your llm even have a look at the updated commit?

[nikolai-vysotskyi]

Yes — the updated commit is correct. Making if (!container) { …; return } a separate check after the !viewContainer warning is exactly right: when the target container is missing and there's no Explorer default (the #804 partial-setup case), it now warns and returns instead of dereferencing undefined. Apologies for the earlier reply — it crossed with your push and was looking at the previous diff. This covers our case; closing #805 in favour of this. Thanks for the quick turnaround!