Process sessions is no longer halted by a failed session#24
Conversation
| 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.
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.
Actually the persister is session specific. can we pass down db_conn?
There was a problem hiding this comment.
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.
benalleng
force-pushed
the
pdk-payjoin-v4
branch
from
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.
benalleng
force-pushed
the
pdk-payjoin-v4
branch
from
53fa516 to
891c782
Compare
benalleng
force-pushed
the
pdk-payjoin-v4
branch
from
e02e919 to
f05ac8b
Compare
benalleng
changed the title
|
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 |
benalleng
force-pushed
the
pdk-payjoin-v4
branch
from
f05ac8b to
66f2448
Compare
2 participants
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.