@@ -526,24 +526,22 @@ export async function waitForDashboardToLoad(section: any): Promise<void> {
526526 const wait = getWaitHelper ( ) ;
527527 logger . info ( 'Waiting for Liberty Dashboard to load' ) ;
528528
529- // Focus the Liberty Tools view before polling. The extension has an
530- // "onView:liberty-dev" activation event — explicitly revealing the view
531- // triggers immediate activation and project scanning instead of waiting
532- // for the extension host to do it passively, which can take 5+ minutes
533- // on cold mac-previous runners after a prior heavy devmode suite.
534- try {
535- await new Workbench ( ) . executeCommand ( 'liberty-dev.focus' ) ;
536- await wait . sleep ( 1000 ) ;
537- } catch {
538- // Non-fatal — falls back to the poll loop below if the command fails
539- }
540-
541529 // Re-fetch a fresh section on every poll iteration. The section reference
542530 // passed in (or obtained just before this call) goes stale on cold runners
543531 // once VS Code rebuilds the sidebar DOM after workspace activation.
544532 // Using a stale reference causes ElementNotInteractableError on every
545533 // getVisibleItems() call, looping forever until timeout.
546534 await wait . forCondition ( async ( ) => {
535+ // Prod the extension to refresh on every iteration. On cold previous
536+ // runners registerTreeDataProvider is not called until the Liberty LS
537+ // JVM has started (extension.ts registers the tree provider only after
538+ // startLangServer resolves). Executing liberty.explorer.refresh forces
539+ // a repopulation once the provider is registered; before that the
540+ // command simply isn't registered and the error is swallowed.
541+ try {
542+ await new Workbench ( ) . executeCommand ( 'liberty.explorer.refresh' ) ;
543+ } catch { /* command not yet registered — keep waiting */ }
544+
547545 try {
548546 const freshSection = await getDashboardSection ( new SideBarView ( ) ) ;
549547 await freshSection . expand ( ) ;
0 commit comments