lb-rs: size-based request timeouts#4108
Conversation
| use crate::model::errors::LbErr; | ||
| use crate::model::pubkey; | ||
|
|
||
| // intended for small requests like metadata transfers and small file uploads |
There was a problem hiding this comment.
| // intended for small requests like metadata transfers and small file uploads | |
| /// intended for small requests like metadata transfers and small file uploads |
and to the one below
| /// size. Timeout will never be less than the default/minimum timeout; it is | ||
| /// safe to pass a zero size. | ||
| pub async fn request_with_size<T: Request>( | ||
| &self, account: &Account, request: T, size: usize, |
There was a problem hiding this comment.
any reason we're not just using the serialized size?
There was a problem hiding this comment.
this approach also works for pulling files
| pub last_modified_by: Username, | ||
| pub owner: Username, | ||
| pub shares: Vec<Share>, | ||
| pub size_bytes: u64, |
There was a problem hiding this comment.
I think size_bytes calculation needs to match the one in server though, it needs to take into account the metadata fee as well. There's a tiny function somewhere that should be trivial to move around
| .value | ||
| .doc_size() | ||
| .unwrap_or_default(); | ||
| docs_to_pull.push((id, remote_hmac, size)); |
There was a problem hiding this comment.
I see why it's not based on the serialized size now
|
I think this is a good move, I would be down to let you just dog food this and tell us if it actually fixes it before merging though |
|
I'm curious to hear how this is been working out for you, I don't experience this as much as you, but I just experienced this recently while using my iPad, and I toggled on airplane mode which I imagine would kill requests but the app never recovered despite airplane mode. |
|
Our investigation detailed in the above issue determined that this is likely not a network timeout related issue |
Fixes #3463 (or at least tries to)
Fileso thatlockbook debug inforeports file size