Skip to content
Snippets Groups Projects

Enable repeat responses to successful Lox requests

Open onyinyang requested to merge onyinyang/lox:duplicate-response into main

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.

Edited by onyinyang

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
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?

  • I suppose for the hashmap, it will amount to the same amount of space, so this might not matter if we move away from the vec of requests.

  • Yes, I think if we can move to a TTL cache just having the request/response hashmap isn't so bad.

  • Please register or sign in to reply
  • 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);
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Please register or sign in to reply
    Loading