step21
commented
3 years ago Closed step21 closed 3 years ago
step21
commented
3 years ago 
xla
commented
3 years ago Hej thanks for reaching out with your issue. Could you provide more context what actions you performed before this happened?
For context the offender is here:
The Lagged variant originates from tokio and might indicate some out of order channel access.
step21
commented
3 years ago As far as I can tell:
xla
commented
3 years ago
- then put machine to sleep - at some point it must have failed, I think after resuming/changing network but I also didn't check constantly so I am not sure
This is very interesting and definitely a case we haven't looked at in detail yet. Do you have a rough idea for how long your machine was in sleep state?
step21
commented
3 years ago @xla It probably was in sleep state for like 30 mins. Maximum 60 mins I would say. But just to state this again, this timeline is not completely certain, as it was running in background.
I might check if I can reproduce it later.
xla
commented
3 years ago Another similar issue propped up.
http://ownpaste.eth.link/#!/view/0x6d04c51b7fb9ad3c4d704512e1aa0c03f1f35060
Nemo157
commented
3 years ago The problem appears to be trying to store Instants inside the serialized WaitingRoom which may be in the past during a future load. Instant doesn't give any guarantee of being able to represent any point in time before the application started.
xla
commented
3 years ago Your analysis is on point. The offender is the unchecked subtraction over in the serde_millis crate we are using:
Nemo157
commented
3 years ago I think the solution would be using SystemTime in any location that gets serialized and passed between application sessions. I did a quick sed s/Instant/SystemTime/g and fix of one location that needed changes and it seems to be working ok now. I'm not sure whether any usage needs extra checks to handle the non-monotonicity of SystemTime though.
xla
commented
3 years ago I think the solution would be using
SystemTimein any location that gets serialized and passed between application sessions. I did a quicksed s/Instant/SystemTime/gand fix of one location that needed changes and it seems to be working ok now. I'm not sure whether any usage needs extra checks to handle the non-monotonicity ofSystemTimethough.
Dope! Would be able to put up a PR with your cahnges?
rudolfs
commented
3 years ago If you're stuck with this issue, but don't want to lose all your data by doing a full reset, here's a quick workaround:
diff --git a/proxy/api/src/bin/clear-waitingroom.rs b/proxy/api/src/bin/clear-waitingroom.rs
new file mode 100644
index 0000000..15e478e
--- /dev/null
+++ b/proxy/api/src/bin/clear-waitingroom.rs
@@ -0,0 +1,19 @@
+use directories::ProjectDirs;
+use kv::*;
+
+fn main() {
+ let store_path = ProjectDirs::from("xyz", "radicle", "radicle-upstream")
+ .expect("couldn't build dirs")
+ .data_dir()
+ .join("store");
+
+ let store = kv::Store::new(kv::Config::new(store_path)).expect("couln't access store");
+ let bucket = store
+ .bucket::<Raw, Raw>(Some("waiting_room"))
+ .expect("coultn't access bucket");
+
+ bucket.clear().expect("couldn't clear bucket");
+ bucket.flush().expect("couln't flush to disk");
+
+ println!("Waiting room cleared.")
+}Run it from the proxy directory:
$ cargo run --bin clear-waitingroom
Finished dev [unoptimized + debuginfo] target(s) in 0.21s
Running `target/debug/clear-waitingroom`
Waiting room cleared.If you're stuck with this issue, but don't want to lose all your data by doing a full reset, here's a quick workaround: ....
- println!("Waiting room cleared.") +}
Run it from the
proxydirectory:$ cargo run --bin clear-waitingroom Finished dev [unoptimized + debuginfo] target(s) in 0.21s Running `target/debug/clear-waitingroom` Waiting room cleared.
thanks, this worked as a workaround.
FintanH
commented
3 years ago Closed via https://github.com/radicle-dev/radicle-upstream/pull/1500
The fix will be available in the next minor release :)