-
Notifications
You must be signed in to change notification settings - Fork 1
Process sessions is no longer halted by a failed session #24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
lianad/src/payjoin/receiver.rs
Outdated
| let mut db_conn = db.connection(); | ||
| for session_id in db_conn.get_all_active_receiver_session_ids() { | ||
| let persister = ReceiverPersister::from_id(Arc::new(db.clone()), session_id.clone()); | ||
| let persister = ReceiverPersister::from_id(Arc::new(db.clone()), session_id.clone()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We had talked about moving db up and just passing the db_conn since it locks so perhaps we could get into trouble locking it above in payjoin_receiver_check
impl DatabaseInterface for sync::Arc<sync::Mutex<dyn DatabaseInterface>> {
fn connection(&self) -> Box<dyn DatabaseConnection> {
self.lock().unwrap().connection()
}
}
However, we access the entire DatabaseInterface in addition to the DatabaseConnection in this function since we need to get the persister for each session_id, perhaps also pass down the persister for each session?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah that would make more sense
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually the persister is session specific. can we pass down db_conn?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am currently passing both db_conn and persister down since the current way we construct the persister is from a DatabaseInterface via db not db_conn, I just construct the persister within the loop.
arminsabouri
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK
714d745 to
53fa516
Compare
The for loop in our receiver session was causing any error in a session to bubble up and completely stop the loop meaning follow-up sessions could not proceed forward.
53fa516 to
891c782
Compare
arminsabouri
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK
e02e919 to
f05ac8b
Compare
|
Even with this change I am still finding there is a fatal panic when there is an expired session. |
I thin this is documented #17 . Probably unrelated to the changes in this PR |
f05ac8b to
66f2448
Compare
The for loop in our receiver and sender session was causing any error in a session to bubble up and completely stop the loop meaning follow-up sessions could not proceed forward.