The-PR-Agent/pr-agent

Git provider GitLab System Info Self-hosted gitlab_webhook server, image pragent/pr-agent:0.46.0-gitlab_webhook, against gitlab.com. The affected code is unchanged on current main. Bug details Occasionally a newly opened merge request gets no review. The open webhook arrives, and the first API call for the merge request returns 404 about two seconds after the MR was created: File "pr_agent/git_providers/gitlab_provider.py", in _get_merge_request mr = self.gl.projects.get(self.id_project).mergerequests.get(self.id_mr) gitlab.exceptions.GitlabGetError: 404: 404 Not found ... ValueError: Failed to get git provider for https://gitlab.com/<group>/<project>/-/merge_requests/39 The token can read the project: it reviewed other MRs in the same project, and /review on the same MR a few minutes later works. We saw it once in about 30 MR openings. The webhook endpoint already answered 200, so GitLab does not redeliver and the MR stays unreviewed without any visible error. Proposed fix: in GitL

apply_repo_settings checks repository .pr_agent.toml sections against the host-section allowlist and the host-only key filter by section name, but Dynaconf treats __ in a key as nesting. A section whose name contains __ therefore lands in a protected section without passing either check. Comment arguments already normalise __ to . and are rejected, so only the repository file path is affected. Suggested direction: normalise __ (or reject section and key names containing it) before the allowlist and host-only checks, and add a test that a protected key set through a __ section name is ignored. Help wanted.

pr_agent/config_loader.py:117-119 loads [tool.pr-agent] from the pyproject.toml at the root of the checked-out repository at import time, without the host-only filter that .pr_agent.toml goes through (REPO_HOST_ONLY_KEYS_BY_SECTION). Where pr-agent runs inside a checkout of the repository it reviews, such as the GitHub Action or the CLI in CI, the repository can set keys meant to be host-only, for example config.extra_config_url and config.global_settings_repo. Suggested direction: apply the same host-only filter to the pyproject section, or drop pyproject loading if nothing relies on it. A test that a host-only key set in pyproject.toml is ignored would cover it. Raised by Qodo on #3850. Help wanted.

AWSSecretsManagerProvider.store_secret (aws_secrets_manager_provider.py:65-73) calls put_secret_value, which only adds a version to an existing secret and raises ResourceNotFoundException otherwise. Its one caller, Bitbucket's /installed (bitbucket_app.py:427), stores a new installation's credentials, so on AWS every new installation fails with a 500. The GCS provider's upload_from_string creates the object, so only AWS is affected. Falling back to create_secret(Name=..., SecretString=...) on ResourceNotFoundException fixes it; a test in tests/unittest/test_aws_secrets_manager_provider.py beside test_store_secret_update_existing covers it. Two notes: the fallback lets /installed create secrets, so it belongs with or after #3923's /installed verification (#3877); and #3923 keys by clientKey, whose pattern allows : and braces, while Secrets Manager names accept only alphanumerics and /_+=.@-, so the name needs a mapping (for example a hash) too. Moto does not enforce that charset, so a m

Git provider Other (all providers: the CLI entrypoint) System Info main at 14292be (also present in v0.46.0 and v0.47.0). Any pr-agent --pr_url=... review run from CI. Bug details configuration.toml lines 79-83 document ignore_pr_title, ignore_pr_target_branches, ignore_pr_source_branches, ignore_pr_labels and ignore_pr_authors as [config] keys, and docs/docs/usage-guide/additional_configurations.md ("Ignoring PRs from specific branches") presents them as general settings. They are evaluated only in should_process_pr_logic (pr_agent/servers/utils.py, around line 331), which the webhook servers call on PR events. pr_agent/cli.py never calls it and reads none of these keys, so on the CLI entrypoint every one of them is silently inert: a repository .pr_agent.toml with ignore_pr_source_branches = ['^renovate/'] is still reviewed on every Renovate branch, and nothing in the log says why. In our deployment we exported CONFIG__IGNORE_PR_SOURCE_BRANCHES for months and carried the real exclusio