Bug: Atlantis with ATLANTIS_DISCARD_APPROVAL_ON_PLAN discards approvals for projects it does not watch

[unique-dominik]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request. Searching for pre-existing feature requests helps us consolidate datapoints for identical requirements into a single place, thank you!
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.

---

Overview of the Issue

When multiple Atlantis instances watch the same repository, an Atlantis instance that does not manage a project touched by a pull request can still cause approvals to be discarded if ATLANTIS_DISCARD_APPROVAL_ON_PLAN=true.

In other words, an Atlantis instance that is not watching or is not responsible for the specific project changed by the PR still dismisses approvals created by another Atlantis instance in the same repository.

Reproduction Steps

1. Configure two Atlantis instances to watch the same repository, each configured for a different set of projects.
2. Enable ATLANTIS_DISCARD_APPROVAL_ON_PLAN=true on one or both instances.
3. Create a PR that touches files for project A (managed by Atlantis A) but not project B (managed by Atlantis B).
4. Let someone approve the fictional plan.
5. Re-push a requested change or trigger plan manually
6. Approval for whole PR gets dismissed by B.

Logs

For that case irrelevant, its a behavioral request.

Environment details

ATLANTIS_DISCARD_APPROVAL_ON_PLAN must be true on both projects.

Actual behavior

An Atlantis instance that is not watching or otherwise not responsible for the project that produced the plan still causes the plan approval to be discarded when it evaluates the PR, even if it has no relevant changes to apply.

Expected behavior

An Atlantis instance should only discard approvals when:

• the instance is configured to watch/handle the project(s) that are part of the PR and
• its own plan shows changes (or at minimum, the instance’s project is affected by the PR).

Impact

• Unnecessary approval dismissal and churn on PRs that touch multiple independent projects.
• Confusing UX for reviewers and developers (approvals disappear despite no relevant changes for some instances).
• Breaks multi-Atlantis workflows where multiple instances legitimately watch the same repository for different projects.

Suggested change

• Make ATLANTIS_DISCARD_APPROVAL_ON_PLAN only trigger a discard when the Atlantis instance’s own project(s) are included in the PR and its plan shows non-empty changes — or otherwise ensure an instance only acts on plans for projects it actually manages.
• Alternatively, add a guard that skips discard logic entirely when the instance determines the PR does not affect any of its configured projects.

Additional Context

How we come up with such a thing?

Due to the strict security nature of our company we separate github from azure automation. Both tho watch the same infrastructure repository.

When the github Atlantis should plan/apply/react but a plan is executed, azure Atlantis comes and waives approvals even though the branch does not touch that project at all!

And yes, we are heavy Atlantis users, we have 16 of them targeting the same repository #sekurity #separationOfConcerns

[dosubot]

Hi @unique-dominik! I'm Dosu and I’m helping the atlantis team.

The root cause is that Atlantis discards PR approvals as soon as a plan is triggered if ATLANTIS_DISCARD_APPROVAL_ON_PLAN is set, without checking whether the instance actually manages any of the affected projects. This happens because the discard logic runs before any project-specific evaluation, so approvals are dismissed even if the instance has no relevant changes to apply. There is currently no guard in the code to restrict this behavior to only the instance's own projects, which leads to approval churn and confusion in multi-instance setups (source).

A recommended workaround is to use GitHub branch protection rules that require all Atlantis status checks to pass before merging. This ensures that all projects are planned and applied successfully, and helps mitigate premature merges and approval churn in multi-instance environments (source).

Currently, there are no configuration options or recent changes that address this bug directly. The suggested fix would be to add a guard so that approval discards only happen when the instance's own projects are affected by the PR.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[unique-dominik]

A lovely answer @dosubot (and I know I chat with an AI). But still I don't really understand why it disrespects projects 👀
We are big Atlantis lovers but that restriction basically stops any user that has more than 1 Atlantis.

[dosubot]

Atlantis discards approvals as soon as a plan is triggered if ATLANTIS_DISCARD_APPROVAL_ON_PLAN is set, but it does this before it knows which projects are actually affected. The discard logic runs right at the start of the plan flow, before Atlantis builds any project-specific context—so it can't tell if the PR touches a project the instance manages or not. This means every Atlantis instance watching the repo will discard approvals, even if it has no relevant changes to apply. There’s no guard or project-level check in the code; it’s just a global flag for the whole instance, not scoped to projects or directories. This is an architectural limitation, not an intentional design for multi-instance setups, and it’s why multi-server workflows see approval churn and confusion (code reference).

The only reliable workaround right now is to use branch protection rules in your VCS to require all relevant Atlantis status checks to pass before merging (community discussion). Atlantis itself doesn’t coordinate or aggregate results across servers, so external orchestration is needed for safe multi-instance workflows.

If you want more technical detail or code references, let me know!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[unique-dominik]

I am a bit disappointed. Why is this check before the project stage? 👁️