Terraform plan in GitHub Actions PR check fails with state lock error

Running into a weird block with our new CI/CD setup for Genesys Cloud resources. We’re trying to use the genesyscloud Terraform provider to manage WEM rules and routing configurations. The plan is simple: run terraform plan on every Pull Request to see what will change, and then run terraform apply only when the PR gets merged into the main branch.

The problem is that the plan step in the PR workflow keeps failing. It throws a state lock error saying the state file is locked by another operation. But I’m pretty sure no other apply is running. I suspect the issue is how we are handling the backend configuration or maybe the remote state locking isn’t playing nice with the parallel nature of GitHub Actions.

Here is the relevant part of our terraform-pr.yml workflow:

name: Terraform Plan on PR

on:
 pull_request:
 branches: [ main ]
 paths:
 - 'infra/**'

jobs:
 plan:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v3
 
 - name: Setup Terraform
 uses: hashicorp/setup-terraform@v2
 with:
 terraform_version: 1.5.0

 - name: Init
 run: terraform init
 env:
 GCS_KEY: ${{ secrets.GENESYS_OAUTH_CLIENT_ID }}
 GCS_SECRET: ${{ secrets.GENESYS_OAUTH_CLIENT_SECRET }}
 GCS_REGION: ${{ secrets.GENESYS_REGION }}

 - name: Plan
 run: terraform plan -out=tfplan
 env:
 GCS_KEY: ${{ secrets.GENESYS_OAUTH_CLIENT_ID }}
 GCS_SECRET: ${{ secrets.GENESYS_OAUTH_CLIENT_SECRET }}
 GCS_REGION: ${{ secrets.GENESYS_REGION }}

And the error output looks like this:

Error: Error acquiring the state lock

Lock Info:
 ID: a1b2c3d4-5678-90ab-cdef-EXAMPLEID
 Path: gen-terraform-state/terraform.tfstate
 Operation: OperationTypeApply
 Who: ci-runner@example.com
 Version: 1.5.0
 Created: 2023-10-27 14:00:00 +0000 UTC
 Info: 

It says OperationTypeApply but I didn’t trigger an apply. Did someone else merge something? Or is the plan step somehow acquiring a lock that conflicts with itself? I tried adding -lock=false to the plan command just to see if it would work, and it did run, but that feels dangerous since we want to prevent accidental overwrites in production.

Is there a specific way to configure the backend or the workflow to handle concurrent plans without locking errors? Or is this a known issue with the Genesys provider and remote state?