Replace Postgresql with Redis - #210
Conversation
| // Since the stream is dropped here, we can now unsubscribe | ||
| pubsub_conn.unsubscribe(&channel_name).await?; | ||
|
|
||
| Ok(data) |
There was a problem hiding this comment.
I think its important testing the database implementation
There was a problem hiding this comment.
there aren't unit tests, but the integration tests do test all functions including async peek.
| let mut conn = self.client.get_async_connection().await?; | ||
| let key = format!("{}:{}", pubkey_id, channel_type); | ||
| conn.set(&key, data.clone()).await?; | ||
| conn.publish(&key, data).await?; |
There was a problem hiding this comment.
this is confusing to me. if we always set the data, why wouldnt we only get it ? we do we also need to publish and subscribe?
There was a problem hiding this comment.
Nice detail oriented catch, this can push a unit value or a simple "updated" string instead.
There was a problem hiding this comment.
maybe its worth writing a test to demonstrate the different use cases?
There was a problem hiding this comment.
which use cases that aren't tested? The only one I reckon is polling which may be done with a near-future payjoin-io crate.
There was a problem hiding this comment.
I think I am mainly confused about when the pub/sub will be utilized rather than the set/get. maybe iam missing something of how this should work in practice
There was a problem hiding this comment.
if the receiver is waiting for a payjoin psbt, it makes a GET request to the endpoint which calls peek. If there's no psbt yet then the redis::get will fail, but it'll subscribe for an update. If before the timeout ends the sender comes and posts a psbt which is redis::set, it'll also publish an event which the receiver is listening for. The receiver knows to redis::get again with a fresh value.
2 participants
Close #131
Close #209 as a side effect