`activate()` aborts when a Forgejo view activates the extension before `vscode.git`, so every command registered after `branchStatusBarController.activate()` is missing

Migrated from Codeberg issue #33. Originally opened by Codeberg user spskeldon on 2026-09-01T17:42:35+02:00.

---

Summary

On a cold window where one of the Forgejo views is visible, the extension is activated by the
implicit onView:forgejo* event, which can fire before vscode.git has activated. activate()
then throws inside getGitExtensionApi(), and because the throw happens partway through activate(),
every command registered after that point is never registered. The visible symptom is
command 'forgejo.showIssueDetails' not found when clicking an issue in the tree — the tree itself
populates normally, because its provider is registered before the throw.

Reproduced on v0.3.25 (latest tag), VS Code 1.135.0, remote-SSH workspace. Deterministic across
three consecutive cold starts on three different days.

Root cause

src/utils/gitUtils.ts:54-63:

function getGitExtensionApi(): ReturnType<GitExtension['getAPI']> | null {
  const extension = getGitExtension();
  const gitExtension = extension?.exports;   // <-- line 56: throws

  if (!extension?.isActive || !gitExtension?.enabled) {   // <-- line 58: never reached
    return null;
  }

  return gitExtension.getAPI(1);
}

VS Code's Extension.exports getter throws Error: Extension 'vscode.git' is not known or not activated when the extension has not been activated yet — it does not return undefined. So the
isActive guard on line 58 is one line too late to do its job: line 56 has already thrown.

The throw propagates up through getGitApi() → BranchStatusBarController.activate() →
activate(), which aborts. In the compiled out/extension.js, branchStatusBarController.activate(context)
sits at line 705 and registerCommand('forgejo.showIssueDetails', ...) at line 710, so that command
and everything registered after it are lost for the lifetime of the extension host.

Why the ordering varies

package.json declares activationEvents: ["onStartupFinished"] and no extensionDependencies.
But the six contributes.views entries generate implicit onView:<id> activation events, and those
fire as soon as a view is restored — which on a cold window with the Forgejo container open is
before vscode.git activates on *.

Failing cold start (extension host log):

08:33:31.927 [info]  _doActivateExtension maxking.forgejo-vscode, activationEvent: 'onView:forgejoIssues'
08:33:34.059 [error] Activating extension maxking.forgejo-vscode failed due to an error:
08:33:34.059 [error] Error: Extension 'vscode.git' is not known or not activated
    at getGitExtensionApi (out/utils/gitUtils.js:74:35)
    at getGitApi (out/utils/gitUtils.js:130:12)
    at BranchStatusBarController.activate (out/statusBar/branchStatusBarController.js:97:46)
    at activate (out/extension.js:705:31)
08:33:34.059 [info]  _doActivateExtension vscode.git, activationEvent: '*'

Then, on every subsequent click in the Issues tree:

11:27:55.266 [error] Error: command 'forgejo.showIssueDetails' not found

Same window after Developer: Reload Window, where the view is not restored fast enough to win:

11:31:16.260 [info] _doActivateExtension vscode.git, activationEvent: '*'
11:31:17.022 [info] _doActivateExtension maxking.forgejo-vscode, activationEvent: 'onStartupFinished'
15:31:17.822Z [INFO] Extension activation complete

No error, all commands present. Nothing else changed — same 0.3.25, same workspace.

Steps to reproduce

1. Open a workspace with a Forgejo remote and leave the Forgejo Issues view expanded in the sidebar.
2. Fully close and reopen the window (or reconnect a remote-SSH workspace) so the view is restored at startup.
3. Check the extension host log for Activating extension maxking.forgejo-vscode failed.
4. Click any issue in the Issues tree → command 'forgejo.showIssueDetails' not found.

Reloading the window usually clears it, which makes the bug look intermittent from the user's side.

Suggested fix

Two independent changes, either of which prevents the abort; both are probably worth doing:

1. Make the guard actually guard. Check isActive before touching exports:

   function getGitExtensionApi(): ReturnType<GitExtension['getAPI']> | null {
     const extension = getGitExtension();
     if (!extension?.isActive) {
       return null;
     }
     const gitExtension = extension.exports;
     if (!gitExtension?.enabled) {
       return null;
     }
     return gitExtension.getAPI(1);
   }
   

   Optionally await extension.activate() instead of bailing, so the status bar works on the first
   window rather than only after a reload.

2. Declare the dependency. Add "extensionDependencies": ["vscode.git"] to package.json so
   VS Code guarantees vscode.git is activated first, whichever event triggers activation.

Separately, wrapping the optional status-bar setup in a try/catch would stop any future error there
from taking the command registrations down with it. Right now, whether a command exists depends on
whether it happens to be registered before or after the status-bar call.

Environment

• forgejo-vscode 0.3.25
• VS Code 1.135.0, Remote-SSH (extension installed on the remote host)
• Server: macOS 26 (Tahoe)
• Forgejo/Gitea instance: self-hosted

Start in src/utils/gitUtils.ts and follow getGitApi() into BranchStatusBarController.activate(), then inspect activate() and package.json for activation ordering. Reproduce a cold start with a restored Forgejo view and check the extension host log. Done means activation no longer aborts when vscode.git is unavailable and forgejo.showIssueDetails plus later commands remain registered.