(It's probably an upstream error. It should be easily mitigable on bat's side but I lack context to say for sure.)

The Dependabot action to update submodules has been failing since at least the last couple of months.

The two runs we can access both fail on the same step:

2025-02-01T03:34:09.3613620Z   proxy | 2025/02/01 03:34:09 [066] GET https://api.github.com:443/repos/sharkdp/bat/contents/assets/syntaxes/02_Extra/JavaScript%20(Babel)?ref=4fc55cfcec44dba3f67bd79cac9ccf64dc18eb08
2025-02-01T03:34:09.3614825Z   proxy | 2025/02/01 03:34:09 [066] * authenticating github api request with token for api.github.com
2025-02-01T03:34:09.4715821Z   proxy | 2025/02/01 03:34:09 [066] 404 https://api.github.com:443/repos/sharkdp/bat/contents/assets/syntaxes/02_Extra/JavaScript%20(Babel)?ref=4fc55cfcec44dba3f67bd79cac9ccf64dc18eb08
2025-02-01T03:34:09.4737486Z updater | 2025/02/01 03:34:09 ERROR <job_956925857> Error during file fetching; aborting: assets/syntaxes/02_Extra/JavaScript (Babel) not found

Previous runs are all deleted because of the GitHub Actions' eviction policy. But there's a Dependabot message in a previously-created PR that reports an error on fetching this same submodule.

I only noticed because I was expecting cmd-help to be auto-bumped and it was not.

I think I have tracked the bug to the GitHub API, I have reported it here.

Mitigation

The bug seems to affect submodule files/mappings that contain spaces in their name. We could change those paths to remove spaces and it should fix this workflow.

e.g.:

# .gitmodules
[submodule "assets/syntaxes/JavaScript (Babel)"]
- 	path = assets/syntaxes/02_Extra/JavaScript (Babel)
+ 	path = assets/syntaxes/02_Extra/JavaScript(Babel)

If the error persists, we may try removing parentheses too. But the only bug I've been able to prove is with spaces.