Git backend storage give-up on sync

[Lunik]

Describe the bug
When Git backend storage fail for some reason (git server restarting for exemple), the storage function fail (obviously). But when the git service is back up, WikiJS never try to save again. It stay in error mode.

To Reproduce
Steps to reproduce the behavior:

• Enable Git as storage backend
  • Configure it so that it work
• Make your Git server unavailable
• Wait until WikiJS tries to save new pages to it
• You will get an expected error of the type (this is the error in my case) in the status windows of the backend

remote: Bad Gateway fatal: unable to access 'https://git.mydomain.fr/wiki_data.git/':
  The requested URL returned error: 502 error: Could not fetch origin 

• Put the Git server back online
• WikiJS never try to sync again

Additional steps :

• Click on Force Sync
  • It sync but don't autosync again

Expected behavior

WikiJS should always try to sync even if the previous sync failed (maybe with a cooldown)

Screenshots
N/A

Host Info (please complete the following information):

• OS: Docker
• Wiki.js version: 2.4.105
• Database engine: MariaDB - 10.5.3

Additional context
Add any other context about the problem here.

[jmvaswani]

Hi !
I would like to contribute to this issue, I currently have my dev environment setup, and I think I need to start off by learning about the scheduler that you guys use.

Can you please guide me to understanding the scheduler workflow? Also any info on the global WIKI object would be super helpful as well.. Thanks!

[jmvaswani]

Hey, I could not reproduce this problem on the development environment, any idea if it has been fixed? Perhaps we could close this issue

Steps performed by me

1. Set up git target
2. Run on default schedule (5M)
3. Cut off internet connectivity and observer failure
4. Restore connectivity and observed successful sync

[imysl0]

Hi @jmvaswani ：

Would you be interested in fixing this issue? I've encountered this problem, but I'm unsure how to fix it:

• The current Git synchronization module is unable to synchronize with a Git repository that contains submodules

[jmvaswani]

Hi @imysl0. Can you explain how did you encounter the issue ? I tried to reproduce it on my dev setup, but didn't have much luck there

[imysl0]

Hi @imysl0. Can you explain how did you encounter the issue ? I tried to reproduce it on my dev setup, but didn't have much luck there

Hi @jmvaswani ：

The link below is an example of using a submodule.
how-to-use-git-submodules

On this basis,

1. Create a main repository A,
2. Add some submodules to subfolders of A (such as S1, S2),
3. Synchronize the Wiki.js settings with repository A.
4. When I commit an md file in the S1 repository, this file cannot be synchronized to the wiki.
5. When I create a page in the S1 folder of Wiki.js, this page cannot be synchronized to the S1 repository.
6. Without considering Wiki.js, I can clone the main repository A and, using appropriate commands, perform commits and pulls in the S1 folder.
   This is the issue I encountered:
   -[ ] The current Git synchronization module is unable to synchronize with a Git repository that contains submodules

Additionally, I encountered another issue where, after different users made modifications and committed them in the Git repository, Wiki.js would pick up these changes and record them in its own database. However, the page's modifier was always the Wiki.js administrator, not the Git commit author. I attempted to fix this issue but was unsuccessful. I have documented my efforts here for reference.
discussions/7274

[BPowell76]

Hey, I could not reproduce this problem on the development environment, any idea if it has been fixed? Perhaps we could close this issue

Steps performed by me

1. Set up git target
2. Run on default schedule (5M)
3. Cut off internet connectivity and observer failure
4. Restore connectivity and observed successful sync

Did the commit actually go through though? It says the operation was successful, but do the changes actually show up in the remote repo?

[TimoKruth]

Verified with a live fail/recover cycle on current v2 main (6f042e97, v2.5.314, PostgreSQL): I can no longer reproduce this bug.

I configured Git storage against an isolated bare repository with a 2-second schedule, removed the remote, and created a page. Scheduled sync entered error with “Could not read from remote repository.” I restored the remote without restarting or reapplying settings. The next scheduled run changed state to operational, cleared the message, and the remote's newest commit became docs: create verification/git-recovery.

Classification: appears fixed; recurring sync now continues after a failed run.