mirror of
https://github.com/facebook/sapling.git
synced 2024-10-09 16:31:02 +03:00
47e92203dc
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 If a previous add_sync_target() call was successful on mononoke side, but we failed to deliver this result to the client (e.g. network issues), then client would just try to retry this call. Before this diff it wouldn't work (i.e. we just fail to create a bookmark because it's already created). This diff fixes it by checking a commit this bookmark points to and checking if it looks like it was created by a previous add_sync_target call. In particular, it checks that remapping state file matches the request parameters, and that config version is the same. Differential Revision: D29848377 fbshipit-source-id: 16687d975748929e5eea8dfdbc9e206232ec9ca6 |
||
|---|---|---|
| .. | ||
| fs | ||
| hg-server | ||
| integration | ||
| locale | ||
| mononoke | ||
| scm | ||
| test_support | ||
| test-data | ||
| .gitignore | ||
| Eden.project.toml | ||