Marcus Nyh
09/28/2026, 1:03 PM<date_time> | 17 | opal_common.sources.api_policy_source |ERROR | Failed to load initial policy from remote API bundle server
Traceback (most recent call last):
File "/usr/local/bin/gunicorn", line 33, in <module>
sys.exit(load_entry_point('gunicorn==26.2.0', 'console_scripts', 'gunicorn')())
File "/usr/local/lib/python3.10/site-packages/gunicorn/app/wsgiapp.py", line 66, in run
WSGIApplication("%(prog)s [OPTIONS] [APP_MODULE]", prog=prog).run()
File "/usr/local/lib/python3.10/site-packages/gunicorn/app/base.py", line 235, in run
super().run()
File "/usr/local/lib/python3.10/site-packages/gunicorn/app/base.py", line 71, in run
Arbiter(self).run()
File "/usr/local/lib/python3.10/site-packages/gunicorn/arbiter.py", line 248, in run
self.manage_workers()
File "/usr/local/lib/python3.10/site-packages/gunicorn/arbiter.py", line 701, in manage_workers
self.spawn_workers()
File "/usr/local/lib/python3.10/site-packages/gunicorn/arbiter.py", line 788, in spawn_workers
self.spawn_worker()
File "/usr/local/lib/python3.10/site-packages/gunicorn/arbiter.py", line 753, in spawn_worker
worker.init_process()
File "/usr/local/lib/python3.10/site-packages/gunicorn/workers/base.py", line 145, in init_process
self.run()
File "/usr/local/lib/python3.10/site-packages/uvicorn/workers.py", line 104, in run
return asyncio_run(self._serve(), loop_factory=self.config.get_loop_factory())
File "/usr/local/lib/python3.10/site-packages/uvicorn/_compat.py", line 60, in asyncio_run
return loop.run_until_complete(main)
File "/usr/local/lib/python3.10/site-packages/opal_common-0.0.0-py3.10.egg/opal_common/sources/base_policy_source.py", line 54, in run
await self.get_initial_policy_state_from_remote()
> File "/usr/local/lib/python3.10/site-packages/opal_common-0.0.0-py3.10.egg/opal_common/sources/api_policy_source.py", line 88, in get_initial_policy_state_from_remote
self.local_git = self.tar_to_git.create_local_git()
File "/usr/local/lib/python3.10/site-packages/opal_common-0.0.0-py3.10.egg/opal_common/git_utils/tar_file_to_local_git_extractor.py", line 56, in create_local_git
local_git = self.commit_local_git(should_init=True)
File "/usr/local/lib/python3.10/site-packages/opal_common-0.0.0-py3.10.egg/opal_common/git_utils/tar_file_to_local_git_extractor.py", line 46, in commit_local_git
local_git.index.add(self.policy_bundle_git_add_pattern)
File "/usr/local/lib/python3.10/site-packages/git/index/base.py", line 925, in add
paths, entries = self._preprocess_add_items(items)
File "/usr/local/lib/python3.10/site-packages/git/index/base.py", line 710, in _preprocess_add_items
paths.append(self._to_relative_path(item))
File "/usr/local/lib/python3.10/site-packages/git/index/base.py", line 696, in _to_relative_path
return _to_relative_path(cast(PathLike, self.repo.working_tree_dir), path)
File "/usr/local/lib/python3.10/site-packages/git/util.py", line 373, in _to_relative_path
raise ValueError("Path %r is not in repository at %r" % (path_str, root_abs))
ValueError: Path '*' is not in repository at '//opal/opal/opal_repo_clone'Ask Inkeep
09/28/2026, 1:03 PMAsk Inkeep
09/28/2026, 1:03 PMTarFileToLocalGitExtractor.commit_local_git() calling local_git.index.add(self.policy_bundle_git_add_pattern) in opal-common/opal_common/git_utils/tar_file_to_local_git_extractor.py, which is the exact same line and file referenced in a report of related behavior with this component(1).
In that report, this same call is described as only staging additions/modifications of files present on disk, and not being able to properly handle certain path patterns, with a suggested fix of replacing it with:
local_git.git.add(self.policy_bundle_git_add_pattern, all=True)
(1)
That report also confirms this is a recognized bug with the index.add() call in this file, and that a corresponding pull request has been opened for it(1).
Since your traceback shows the identical failing call (local_git.index.add(self.policy_bundle_git_add_pattern)) raising a ValueError on the path pattern, this matches the underlying mechanism described in that report(1).
For general context on how the API bundle source is supposed to work — the OPAL server fetches the bundle.tar.gz, extracts it, and creates a git repo from its contents to track changes(2). If you'd like, I can also point you to how to configure polling vs. webhook detection for this bundle server(2).Ask Inkeep
09/28/2026, 1:03 PMdavid
09/28/2026, 1:37 PMindex.add() validates paths. Inside the container, the opal user's home dir is //opal (double slash). That means ~/opal in the example compose expands to //opal/opal, and the new GitPython check rejects every path in a repo rooted under //. The #900 link the bot shared is a different issue, so no code changes are needed on your side.
Quick fix to try in`docker-compose-api-policy-source-example.yml`, change
OPAL_POLICY_REPO_CLONE_PATH=~/opal
to
OPAL_POLICY_REPO_CLONE_PATH=/opal/opal
Let me know if that works 🙂Marcus Nyh
09/28/2026, 1:42 PM