-
Notifications
You must be signed in to change notification settings - Fork 295
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
mononoke: make change_target_config return result immediately if it w…
…as computed Summary: # Goal of the stack There goal of this stack is to make megarepo api safer to use. In particular, we want to achieve: 1) If the same request is executed a few times, then it won't cause corrupt repo in any way (i.e. it won't create commits that client didn't intend to create and it won't move bookmarks to unpredictable places) 2) If request finished successfully, but we failed to send the success to the client, then repeating the same request would finish successfully. Achieving #1 is necessary because async_requests_worker might execute a few requests at the same time (though this should be rare). Achieveing #2 is necessary because if we fail to send successful response to the client (e.g. because of network issues), we want client to retry and get this successful response back, so that client can continue with their next request. In order to achieve #1 we make all bookmark move conditional i.e. we move a bookmark only if current location of the bookmark is at the place where client expects it. This should help achieve goal #1, because even if we have two requests executing at the same time, only one of them will successfully move a bookmark. However once we achieve #1 we have a problem with #2 - if a request was successful, but we failed to send a successful reply back to the client then client will retry the request, and it will fail, because a bookmark is already at the new location (because previous request was successful), but client expects it to be at the old location (because client doesn't know that the request was succesful). To fix this issue before executing the request we check if this request was already successful, and we do it heuristically by checking request parameters and verifying the commit remapping state. This doesn't protect against malicious clients, but it should protect from issue #2 described above. So the whole stack of diffs is the following: 1) take a method from megarepo api 2) implement a diff that makes bookmark moves conditional 3) Fix the problem #2 by checking if a previous request was successful or not # This diff Same as with D29848377 - if result was already computed and client retries the same request, then return it. Differential Revision: D29874802 fbshipit-source-id: ebc2f709bc8280305473d6333d0725530c131872
- Loading branch information
1 parent
47e9220
commit c9473f7
Showing
2 changed files
with
214 additions
and
11 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters