A number of Lambda API calls allow for a RevisionId argument to ensure that the operation only continues if the current revision of the Lambda function matches, very similar to an atomic Compare-And-Swap operation. However, this RevisionId appears to be useless for performing some atomic operations, for the following reason:
Suppose I want to update a function's code and then publish it, in 2 separate steps (I know it can be done in 1 step, but this does not interest me, because I cannot set the description of a published version in 1 update/publish step...it must be done in 2 steps). The update_function_code call returns a RevisionId that corresponds to the "in progress" update of the function. This RevisionId cannot be used because it will change once the function becomes active/updated. This new RevisionId can only be obtained by get_function.
Update code -> RevisionId A (in progress) -> RevisionId B (updated/active) -> Get Function -> RevisionId B -> Publish Function
There exists a race condition due to the fact that I must call get_function
in order to get the current RevisionId before I continue with publishing my function. This race condition makes it impossible create an atomic sequence of operations that includes a update_function_code
operation, because the RevisionId that it returns cannot be relied on, and has to be refreshed with a get_function
call. Concurrently, another operation could change the RevisionId, and you wouldn't know, because you're depending on get_function
to return an unknown RevisionId.