`.lock` producing a weird behaviour after `4.0.0`

[tiagonbotelho]

👋 I've recently updated our workflow to 4.0.0 and noticed that whenever I issued a .lock/.unlock I would get a repeated set of messages as the image below shows.

Upon further investigation I was able to track down the following error from the logs of the branch-deploy action run:

Error: HttpError: Invalid request.

"sha" wasn't supplied.
    at /home/runner/work/_actions/github/branch-deploy/0b617a0ced1[42](https://github.com/npm/breach-api/actions/runs/4133871384/jobs/7144298067#step:2:43)f5f2b27302d61557637ba633dcc/webpack:/branch-deploy-action/node_modules/@octokit/request/dist-node/index.js:86:1
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at createLock (/home/runner/work/_actions/github/branch-deploy/0b617a0ced142f5f2b27302d61557637ba633dcc/webpack:/branch-deploy-action/src/functions/lock.js:37:1)
    at lock (/home/runner/work/_actions/github/branch-deploy/0b617a0ced142f5f2b27302d61557637ba633dcc/webpack:/branch-deploy-action/src/functions/lock.js:269:1)
    at run (/home/runner/work/_actions/github/branch-deploy/0b617a0ced142f5f2b27302d61557637ba633dcc/webpack:/branch-deploy-action/src/main.js:229:1)
Error: Invalid request.

"sha" wasn't supplied.

If we look closer into the line that this error is reporting, it seems to suggest that this has something to do with how we are using GitHub's API.

Looking at the documentation I see the following

Required if you are updating a file. The blob SHA of the file being replaced.

Which hints at us potentially attempting to update the lock.json file using GitHub's API perhaps? 🤔

[tiagonbotelho]

Closing as @GrantBirki and I already found the root cause of the issue stemming from the fact that we had multiple workflows using branch-deploy for the same repo and using the same lock prompt, which caused multiple workflows to try and run at the same time and contend for the same lock