Enable repeat responses to successful Lox requests
Closes #74
This MR stores Lox requests and their responses for a period of time in order to enable exact repeat responses. After a user has sent a Lox request, their connection could be interrupted, preventing them from receiving a response from the Lox authority. Prior to this change, this type of interruption would have resulted in the user being locked out of further interaction with Lox. This change stores each seen Lox request and its exact response for a brief period (MAX_STORAGE_DAYS
, currently set to 3 days) and returns the previously sent response if the same request is seen.
Alongside the HashMap
of Request, Responses, a Queue of Vec<String>
stores all of the requests seen in a day. When the day changes, the front entry is removed from the Queue and each of matching request, response pairs are removed from the hashmap as well.
Merge request reports
Activity
added 1 commit
- 43703be5 - Add logic for responding to short-term duplicate requests
requested review from @cohosh
added 9 commits
-
43703be5...b0860354 - 8 commits from branch
tpo/anti-censorship:main
- fdc9e1b6 - Add logic for responding to short-term duplicate requests
-
43703be5...b0860354 - 8 commits from branch
assigned to @onyinyang
added 1 commit
- a09672dc - Add logic for responding to short-term duplicate requests
added 1 commit
- 718f5a91 - Add logic for responding to short-term duplicate requests
added 1 commit
- b89caad0 - Add logic for responding to short-term duplicate requests
added 1 commit
- b0eac986 - Add logic for responding to short-term duplicate requests
added 3 commits
-
b0eac986...c53c8a8d - 2 commits from branch
tpo/anti-censorship:main
- 80b82e39 - Add logic for responding to short-term duplicate requests
-
b0eac986...c53c8a8d - 2 commits from branch
added 11 commits
-
80b82e39...e3fb0b6b - 10 commits from branch
tpo/anti-censorship:main
- e52c6fa7 - Add logic for responding to short-term duplicate requests
-
80b82e39...e3fb0b6b - 10 commits from branch
I'll review this later this week. For big MRs like this, can you give a high level description of the changes you made? For example, see the description for !147
Clippy is failing but that is unrelated to this MR and I've opened !322 (merged) to address it, but this passes tests locally and should be fine to review.
Yep, passing with !322 (merged).
added 10 commits
-
bad64815...434237eb - 6 commits from branch
tpo/anti-censorship:main
- 2f5f0c9d - Minor fmt fixes
- cf52b39b - Add additional fields to lox-context to store request/responses
- be3522e9 - Add store_request function for requests and responses
- 24adbcee - Add remove_expired_requests function
Toggle commit list-
bad64815...434237eb - 6 commits from branch
added 9 commits
-
24adbcee...5dd13af4 - 5 commits from branch
tpo/anti-censorship:main
- f92d845c - Minor fmt fixes
- 4ee4ede7 - Add additional fields to lox-context to store request/responses
- 0cde38ec - Add store_request function for requests and responses
- ba2b30af - Add remove_expired_requests function
Toggle commit list-
24adbcee...5dd13af4 - 5 commits from branch
379 390 result 380 391 } 381 392 393 pub fn remove_expired_requests(&self) { 394 if self.request_keys.lock().unwrap().len() > MAX_REQUEST_STORAGE_DAYS { 395 let expired_requests = self.request_keys.lock().unwrap().pop_front().unwrap(); 396 for request in expired_requests { 397 self.request_table.lock().unwrap().remove(&request); 398 } 399 } 400 } 401 402 pub fn store_request(&self, req_string: String, response: String) { Do we really need to be storing the entire json of the request as IDs in this request table? Why not use
&req.id
like we do for the spent tokens table? This will save a lot of space and be robust against any changes to the encoding of credentials that we make later.Is there a case where a single req.id could be used for multiple requests (for example,
check_blockage
and migration)? In that case, maybe we can use just the id and the type of request as the key?
398 } 399 } 400 } 401 402 pub fn store_request(&self, req_string: String, response: String) { 403 self.request_table 404 .lock() 405 .unwrap() 406 .insert(req_string.clone(), response.clone()); 407 if self.day.lock().unwrap().eq(&self.today()) { 408 let mut existing_requests = self.request_keys.lock().unwrap().pop_back().unwrap(); 409 existing_requests.push(req_string); 410 self.request_keys 411 .lock() 412 .unwrap() 413 .push_front(existing_requests); - Comment on lines +408 to +413
You're using
pop_back()
to get today's queue, but thenpush_front()
to add it back once you've modified it. Shouldn't this bepush_back()
so that the queue is in the right spot for today?Edited by Cecylia Bocovich changed this line in version 13 of the diff