RequestPermissionDenied: File has already been withdrawn from request

[inglesp]

On Friday 27th December between 11:25 and 12:19, there were a few (six) occurrences of airlock.exceptions.RequestPermissionDenied: File has already been withdrawn from request in the Airlock logs. These are the only occurrences going back to November 13th. (As far as I can tell (with just airlock/logs --since="2024-01-01") we don't have earlier application logs.)

There were attempts to withdraw five different files from request 01JF3067D6887CBWS30W8M5FCX. It's not clear from the logs which user triggered the exception but I've dug it out of the database and have started a conversation in Slack to try to understand what was going on.

After re-running, I decided the easiest thing to do was withdraw a load of files from my request, and add the ones that I definitely need and are definitely the correct versions. I didn’t get any error messages while I was doing it, except sometimes just a 401 page not found, but I was able to go back in and it worked when I tried a second time.

(Might the user have meant "404" instead of "401"? I don't know whether we show error codes on the server.)

The button linking to the file_withdraw view is only enabled when permissions.check_user_can_withdraw_file_from_request() passes. This is the same check that we see failing in the traceback.

The exception is not triggered in the following test which tries to withdraw the file twice:

def test_double_withdraw(airlock_client):
    airlock_client.login(username="author", workspaces=["test1"], output_checker=False)

    release_request = factories.create_request_at_status(
        "test1",
        author=airlock_client.user,
        status=RequestStatus.PENDING,
        files=[
            factories.request_file("group", "path/test.txt"),
        ],
    )

    response = airlock_client.post(
        f"/requests/withdraw/{release_request.id}/group/path/test.txt",
    )
    assert response.status_code == 302

    response = airlock_client.post(
        f"/requests/withdraw/{release_request.id}/group/path/test.txt",
    )
    assert response.status_code == 302

Instead, the second response is a 404 (from here).

My only hypothesis is that the user triggered two withdrawals in quick succession, and they ran in parallel.