Are clients notified when a subscription task exists? #1223
-
I am writing some tests to ensure my client task reconnects if a jsonrpc subscription is dropped (I am ignoring the websocket going down for now and am just focusing on the subscription ending). Does jsonrpsee have a mechanism to notify subscribers that the server closed the subscription? Or is that just not a thing? I was looking through the code but couldn't find anything. For reference, this is the code where the impl GethServer for GethImpl {
async fn eth_subscribe(
&self,
pending: PendingSubscriptionSink,
subscription_target: String,
full_txs: Option<bool>,
) -> SubscriptionResult {
use jsonrpsee::server::SubscriptionMessage;
tracing::debug!("received eth_subription request");
assert_eq!(
("newPendingTransactions", Some(true)),
(&*subscription_target, full_txs),
"the mocked geth server only supports the `eth_subscribe` RPC with
parameters [\"newPendingTransaction\", true]",
);
let sink = pending.accept().await?;
let mut rx = self.command.subscribe();
loop {
tokio::select!(
biased;
() = sink.closed() => break,
Ok(cmd) = rx.recv() => {
match cmd {
SubscriptionCommand::Abort => {
tracing::debug!("abort command received; exiting eth_subscription");
break;
}
SubscriptionCommand::Send(tx) => {
let _ = sink.send(SubscriptionMessage::from_json(&tx)?).await?;
}
}
}
);
}
Ok(())
}
} EDIT: I can see that there used to be a function |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
After looking through the git history I found this PR: #1034 So the solution is to return an SubscriptionCommand::Abort => {
tracing::debug!("abort command received; exiting eth_subscription");
break Err("abort command received".into());
} |
Beta Was this translation helpful? Give feedback.
-
Yeah, we tried to explain it https://github.com/paritytech/jsonrpsee/blob/master/CHANGELOG.md#subscription-api-is-changed. If your subscription method returns |
Beta Was this translation helpful? Give feedback.
After looking through the git history I found this PR: #1034
So the solution is to return an
Err("reason".into())
as theSubscriptionResult
in the handler instead of explicitly closing the connection as was done before, bascially this: