foam.foam-vscode breaks vsls-contrib.gitdoc; requires GitDoc Enable/Disable/Enable command sequence on every new session to function.

[AJMansfield]

Describe the bug

Some time before August 2024, GitDoc started to behave strangely with regards to its enable/disable status. Each time I launch VSCode, the extension appears to start disabled (despite configurations that should enable it), and only becomes functional after running commands to enable, disable, and then re-enable it a second time.

I've isolated this issue to an interaction specifically with the Foam extension. Disabling foam.foam-vscode completely resolves these symptoms, and re-enabling it brings them back, even when there are no other extensions other than it and vsls-contrib.gitdoc. This exact set of symptoms occurs across both of the computers and in both of the workspaces I regularly use these extensions on.

Enable/Disable Stateful Behavior

For the sake of being fully explicit, there seem to be four different system states involved, which I'll label State A through State D:

State A is the proper enabled and running state. The book icon is visible in the bottom bar whenever I have a file open that it's configured to operate on, auto-commits are created automatically when files are changed, and the GitDoc: Disable and GitDoc: Commit commands are visible in the command palette. If I close VSCode, then start VSCode, I expect it to re-open in State A; however, it instead launches in what I'm labeled State B.

State B appears to be a disabled state. GitDoc is not running, no book icon is visible, no auto-commits are created, and only the GitDoc: Enable command is visible in the palette. Running GitDoc: Enable transitions the system to State C (not to State A).

State C is a sort of pseudo-enabled state. The book icon is not visible on any configured file, and commits are not created automatically when files are changed, but he GitDoc: Disable and GitDoc: Commit commands are visible in the palette and GitDoc: Enable is not. Running GitDoc: Commit does successfully create a commit, but leaves the system in State C. Running GitDoc: Disable transitions the system to State D.

State D is also a 'disabled' state, with the same visible symptoms as State B, except that running GitDoc: Enable transitions the system to the (desired) State A (not to State C).

Steps to Reproduce the Bug or Issue

With vsls-contrib.gitdoc as the only enabled extension, foam.foam-vscode disabled, and settings set to include "gitdoc.enabled": true as a config key, closed VSCode and launch VSCode. Observe that the system is immediately in State A after launch, without any further intervention.

Re-enable foam.foam-vscode. Close VSCode and launch VSCode. Observe State B described above. Issue the GitDoc: Enable command. Observe State C. Issue the GitDoc: Disable command. Observe State D. Issue the GitDoc: Enable command. Observe State A.

Expected behavior

I expect that GitDoc should function consistently and launch as configured immediately to State A, regardless of Foam's presence or configuration.

Operating System Version

Windows 10; Windows 11

Visual Studio Code Version

1.96.2

Additional context

Workspace Configuration

My workspace configures Foam and GitDoc via config keys in the .vscode/settings.json file located relative to the workspace root, the relevant lines of which are:

{
  "foam.edit.linkReferenceDefinitions": "off",
  "foam.openDailyNote.directory": "journal",
  "foam.openDailyNote.titleFormat": "fullDate",
  "gitdoc.enabled": true,
  "gitdoc.filePattern": "**/*",
  "gitdoc.commitValidationLevel": "none",
}

The last two lines were added recently as another attempts to try to resolve it this issue; but the problem occurs regardless of whether those values are inherited from the defaults or specified explicitly in the workspace settings.

This workspace root is also the git repository root; with these settings captured as part of the version control for this repository.

No extensions other than foam.foam-vscode, vsls-contrib.gitdoc, and the default vscode.* extensions are installed and enabled.

Software Versions

VSCode About

Version: 1.96.2 (system setup)
Commit: fabdb6a30b49f79a7aba0f2ad9df9b399473380f
Date: 2024-12-19T10:22:47.216Z
Electron: 32.2.6
ElectronBuildId: 10629634
Chromium: 128.0.6613.186
Node.js: 20.18.1
V8: 12.8.374.38-electron.0
OS: Windows_NT x64 10.0.22631

GitDoc Installation Info

Identifier	vsls-contrib.gitdoc
Version	0.2.3
Last Updated	2024-12-27, 14:29:58
Size	2.5 MB

Foam Installation Info

Identifier	foam.foam-vscode
Version	0.26.4
Last Updated	2024-11-13, 16:09:33
Size	1.5 MB

Extension Host Logs

Here's the Extension Host logs for each of these states.
Starting in State B, I get:

2025-01-11 12:23:00.996 [info] Extension host with pid ***** started
2025-01-11 12:23:00.996 [info] Skipping acquiring lock for c:\Users\*****\AppData\Roaming\Code\User\workspaceStorage\********************************.
2025-01-11 12:23:01.293 [info] ExtensionService#_doActivateExtension vscode.github-authentication, startup: false, activationEvent: 'onAuthenticationRequest:github'
2025-01-11 12:23:01.346 [info] ExtensionService#_doActivateExtension vscode.emmet, startup: false, activationEvent: 'onLanguage'
2025-01-11 12:23:01.373 [info] ExtensionService#_doActivateExtension vscode.extension-editing, startup: false, activationEvent: 'onLanguage:markdown'
2025-01-11 12:23:01.396 [info] ExtensionService#_doActivateExtension vscode.markdown-language-features, startup: false, activationEvent: 'onLanguage:markdown'
2025-01-11 12:23:01.536 [info] ExtensionService#_doActivateExtension vscode.configuration-editing, startup: false, activationEvent: 'onLanguage:jsonc'
2025-01-11 12:23:01.555 [info] ExtensionService#_doActivateExtension vscode.json-language-features, startup: false, activationEvent: 'onLanguage:jsonc'
2025-01-11 12:23:01.641 [info] ExtensionService#_doActivateExtension vscode.typescript-language-features, startup: false, activationEvent: 'onLanguage:jsonc'
2025-01-11 12:23:02.313 [info] ExtensionService#_doActivateExtension vscode.git-base, startup: true, activationEvent: '*', root cause: vscode.git
2025-01-11 12:23:02.317 [info] ExtensionService#_doActivateExtension foam.foam-vscode, startup: true, activationEvent: 'workspaceContains:.vscode/foam.json'
2025-01-11 12:23:02.581 [info] ExtensionService#_doActivateExtension vscode.git, startup: true, activationEvent: '*'
2025-01-11 12:23:02.694 [info] ExtensionService#_doActivateExtension vscode.github, startup: true, activationEvent: '*'
2025-01-11 12:23:02.750 [info] ExtensionService#_doActivateExtension vscode.markdown-math, startup: false, activationEvent: 'api', root cause: vscode.markdown-language-features
2025-01-11 12:23:03.789 [info] Eager extensions activated
2025-01-11 12:23:03.899 [info] ExtensionService#_doActivateExtension vscode.debug-auto-launch, startup: false, activationEvent: 'onStartupFinished'
2025-01-11 12:23:03.904 [info] ExtensionService#_doActivateExtension vscode.merge-conflict, startup: false, activationEvent: 'onStartupFinished'
2025-01-11 12:23:03.932 [info] ExtensionService#_doActivateExtension vsls-contrib.gitdoc, startup: false, activationEvent: 'onStartupFinished'

No additional log entries appear when running any of the commands that transition the issue into one of the other states.

[AJMansfield]

Cross-posted with lostintangent/gitdoc#88.

[riccardoferretti]

First of all thanks for the thorough description of the bug @AJMansfield
I am quite surprised by the behavior, as the two extensions are completely separated, and I can't think of any overlapping functionality.
The only connection is that gitdoc was part of the Foam recommended extension set.
I personally don't use git (therefore no gitdoc) for Foam, so I haven't experienced the issue.

Looking at the release log, in October of last year we started the work to make Foam a web extension - again I don't believe this should interfere with gitdoc. I am not seeing anything on their release log that would hint at a conflict either..

Let's see also if @lostintangent has any thoughts about the issue.

[AJMansfield]

October of last year

Apologies for the red herring! I just dug through my git history again, looking for commits that might indirectly represent this issue -- i.e. a large set of changes piling up without me noticing the lack of auto-commits, getting committed all at once -- and I've found several that are much earlier than this.

October 26th is a date I have evidence I was trying to troubleshoot this issue, but I've got commits that show the expected symptoms on August 26 (from changes accumulated after August 12), and also maybe another July 24 (from everything after July 15).

There's also commits that look a bit similar even earlier, e.g. one May 10, one February 12; but those lack the large time gaps to their next ancestor and it's difficult to disentangle that far back, what was a software issue vs config/workflow issue vs actual large change thanks to different migrations I was doing at that point.

[SenMorgan]

I am experiencing the same behavior as well.