Unexpected change in locking behaviour

[marksumm]

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

A previously working configuration consisting of several custom workflows in the same directory, all using the default workspace, but with different .tfvars files and Terraform state files for each, now encounters the famous error "the ... workspace at path ... is currently locked by another command that is running for this pull request."

Reproduction Steps

Note that this only happens when an attempt is made to run apply on multiple workflows in the same directory. It does not happen during plan or during a single apply.

Also note that parallel_plan and parallel_apply are both disabled.

This has nothing to do with commits in quick succession.

Environment details

• Atlantis version: 0.35.1
• Deployment method: Azure App Service

Additional Context

It seems that something has changed in very recent Atlantis versions, and this has exposed the fact that locks are not really isolated by project name. I know that an attempt was made to include the project name in the lock, but from what I can see it is not actually being included. See #4192 (comment)

[dosubot]

There is a known bug in Atlantis where the working directory gets refreshed before the lock is checked, which can cause locking errors when running multiple workflows in the same directory—even if they use different project names, .tfvars, or state files. This happens because the lock check occurs too late, after the working directory has already been modified, leading to conflicts and the error you're seeing. The intended behavior is for the lock to be checked before the directory is refreshed, but this isn't happening in the current implementation (details here).

While the core locking logic does include the project name in the lock key, there may be incomplete implementation or edge cases—especially with custom workflows—where project-level isolation isn't fully respected. At the moment, there isn't a documented workaround to restore the previous behavior or guarantee project-level lock isolation in all scenarios. If you need strict isolation, you may need to avoid running concurrent applies in the same directory until this bug is addressed.

To reply, just mention @dosu.

---

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

[bschaatsbergen]

Hey @marksumm,

Thanks for raising this. I’ve noticed similar behavior, and it looks closely related to the issue described in #5708. We’re looking into it and will keep you posted.

[jamengual]

can anyone here confirm the fix using the dev atlantis image please?

[albertorm95]

can anyone here confirm the fix using the dev atlantis image please?

Hello, I just tested v0.36.0 and still have the same error

[jamengual]

@albertorm95 are you in slack?
What version works for you? 0.35.0?

[albertorm95]

Hey! @jamengual yes let me ping you.

This is the thread: https://cloud-native.slack.com/archives/C06DMCR0NFQ/p1753802036499069?thread_ts=1753802036.499069&cid=C06DMCR0NFQ