2025-07-19 01:32:03 -04:00
|
|
|
use std::collections::HashMap;
|
chore: introduce OutgoingMessageSender (#1622)
Previous to this change, `MessageProcessor` had a
`tokio::sync::mpsc::Sender<JSONRPCMessage>` as an abstraction for server
code to send a message down to the MCP client. Because `Sender` is cheap
to `clone()`, it was straightforward to make it available to tasks
scheduled with `tokio::task::spawn()`.
This worked well when we were only sending notifications or responses
back down to the client, but we want to add support for sending
elicitations in #1623, which means that we need to be able to send
_requests_ to the client, and now we need a bit of centralization to
ensure all request ids are unique.
To that end, this PR introduces `OutgoingMessageSender`, which houses
the existing `Sender<OutgoingMessage>` as well as an `AtomicI64` to mint
out new, unique request ids. It has methods like `send_request()` and
`send_response()` so that callers do not have to deal with
`JSONRPCMessage` directly, as having to set the `jsonrpc` for each
message was a bit tedious (this cleans up `codex_tool_runner.rs` quite a
bit).
We do not have `OutgoingMessageSender` implement `Clone` because it is
important that the `AtomicI64` is shared across all users of
`OutgoingMessageSender`. As such, `Arc<OutgoingMessageSender>` must be
used instead, as it is frequently shared with new tokio tasks.
As part of this change, we update `message_processor.rs` to embrace
`await`, though we must be careful that no individual handler blocks the
main loop and prevents other messages from being handled.
---
[//]: # (BEGIN SAPLING FOOTER)
Stack created with [Sapling](https://sapling-scm.com). Best reviewed
with [ReviewStack](https://reviewstack.dev/openai/codex/pull/1622).
* #1623
* __->__ #1622
* #1621
* #1620
2025-07-19 00:30:56 -04:00
|
|
|
use std::sync::atomic::AtomicI64;
|
|
|
|
|
use std::sync::atomic::Ordering;
|
|
|
|
|
|
|
|
|
|
use codex_core::protocol::Event;
|
|
|
|
|
use mcp_types::JSONRPC_VERSION;
|
|
|
|
|
use mcp_types::JSONRPCError;
|
|
|
|
|
use mcp_types::JSONRPCErrorError;
|
|
|
|
|
use mcp_types::JSONRPCMessage;
|
|
|
|
|
use mcp_types::JSONRPCNotification;
|
|
|
|
|
use mcp_types::JSONRPCRequest;
|
|
|
|
|
use mcp_types::JSONRPCResponse;
|
|
|
|
|
use mcp_types::RequestId;
|
|
|
|
|
use mcp_types::Result;
|
|
|
|
|
use serde::Serialize;
|
2025-07-19 01:32:03 -04:00
|
|
|
use tokio::sync::Mutex;
|
chore: introduce OutgoingMessageSender (#1622)
Previous to this change, `MessageProcessor` had a
`tokio::sync::mpsc::Sender<JSONRPCMessage>` as an abstraction for server
code to send a message down to the MCP client. Because `Sender` is cheap
to `clone()`, it was straightforward to make it available to tasks
scheduled with `tokio::task::spawn()`.
This worked well when we were only sending notifications or responses
back down to the client, but we want to add support for sending
elicitations in #1623, which means that we need to be able to send
_requests_ to the client, and now we need a bit of centralization to
ensure all request ids are unique.
To that end, this PR introduces `OutgoingMessageSender`, which houses
the existing `Sender<OutgoingMessage>` as well as an `AtomicI64` to mint
out new, unique request ids. It has methods like `send_request()` and
`send_response()` so that callers do not have to deal with
`JSONRPCMessage` directly, as having to set the `jsonrpc` for each
message was a bit tedious (this cleans up `codex_tool_runner.rs` quite a
bit).
We do not have `OutgoingMessageSender` implement `Clone` because it is
important that the `AtomicI64` is shared across all users of
`OutgoingMessageSender`. As such, `Arc<OutgoingMessageSender>` must be
used instead, as it is frequently shared with new tokio tasks.
As part of this change, we update `message_processor.rs` to embrace
`await`, though we must be careful that no individual handler blocks the
main loop and prevents other messages from being handled.
---
[//]: # (BEGIN SAPLING FOOTER)
Stack created with [Sapling](https://sapling-scm.com). Best reviewed
with [ReviewStack](https://reviewstack.dev/openai/codex/pull/1622).
* #1623
* __->__ #1622
* #1621
* #1620
2025-07-19 00:30:56 -04:00
|
|
|
use tokio::sync::mpsc;
|
2025-07-19 01:32:03 -04:00
|
|
|
use tokio::sync::oneshot;
|
|
|
|
|
use tracing::warn;
|
chore: introduce OutgoingMessageSender (#1622)
Previous to this change, `MessageProcessor` had a
`tokio::sync::mpsc::Sender<JSONRPCMessage>` as an abstraction for server
code to send a message down to the MCP client. Because `Sender` is cheap
to `clone()`, it was straightforward to make it available to tasks
scheduled with `tokio::task::spawn()`.
This worked well when we were only sending notifications or responses
back down to the client, but we want to add support for sending
elicitations in #1623, which means that we need to be able to send
_requests_ to the client, and now we need a bit of centralization to
ensure all request ids are unique.
To that end, this PR introduces `OutgoingMessageSender`, which houses
the existing `Sender<OutgoingMessage>` as well as an `AtomicI64` to mint
out new, unique request ids. It has methods like `send_request()` and
`send_response()` so that callers do not have to deal with
`JSONRPCMessage` directly, as having to set the `jsonrpc` for each
message was a bit tedious (this cleans up `codex_tool_runner.rs` quite a
bit).
We do not have `OutgoingMessageSender` implement `Clone` because it is
important that the `AtomicI64` is shared across all users of
`OutgoingMessageSender`. As such, `Arc<OutgoingMessageSender>` must be
used instead, as it is frequently shared with new tokio tasks.
As part of this change, we update `message_processor.rs` to embrace
`await`, though we must be careful that no individual handler blocks the
main loop and prevents other messages from being handled.
---
[//]: # (BEGIN SAPLING FOOTER)
Stack created with [Sapling](https://sapling-scm.com). Best reviewed
with [ReviewStack](https://reviewstack.dev/openai/codex/pull/1622).
* #1623
* __->__ #1622
* #1621
* #1620
2025-07-19 00:30:56 -04:00
|
|
|
|
|
|
|
|
pub(crate) struct OutgoingMessageSender {
|
|
|
|
|
next_request_id: AtomicI64,
|
|
|
|
|
sender: mpsc::Sender<OutgoingMessage>,
|
2025-07-19 01:32:03 -04:00
|
|
|
request_id_to_callback: Mutex<HashMap<RequestId, oneshot::Sender<Result>>>,
|
chore: introduce OutgoingMessageSender (#1622)
Previous to this change, `MessageProcessor` had a
`tokio::sync::mpsc::Sender<JSONRPCMessage>` as an abstraction for server
code to send a message down to the MCP client. Because `Sender` is cheap
to `clone()`, it was straightforward to make it available to tasks
scheduled with `tokio::task::spawn()`.
This worked well when we were only sending notifications or responses
back down to the client, but we want to add support for sending
elicitations in #1623, which means that we need to be able to send
_requests_ to the client, and now we need a bit of centralization to
ensure all request ids are unique.
To that end, this PR introduces `OutgoingMessageSender`, which houses
the existing `Sender<OutgoingMessage>` as well as an `AtomicI64` to mint
out new, unique request ids. It has methods like `send_request()` and
`send_response()` so that callers do not have to deal with
`JSONRPCMessage` directly, as having to set the `jsonrpc` for each
message was a bit tedious (this cleans up `codex_tool_runner.rs` quite a
bit).
We do not have `OutgoingMessageSender` implement `Clone` because it is
important that the `AtomicI64` is shared across all users of
`OutgoingMessageSender`. As such, `Arc<OutgoingMessageSender>` must be
used instead, as it is frequently shared with new tokio tasks.
As part of this change, we update `message_processor.rs` to embrace
`await`, though we must be careful that no individual handler blocks the
main loop and prevents other messages from being handled.
---
[//]: # (BEGIN SAPLING FOOTER)
Stack created with [Sapling](https://sapling-scm.com). Best reviewed
with [ReviewStack](https://reviewstack.dev/openai/codex/pull/1622).
* #1623
* __->__ #1622
* #1621
* #1620
2025-07-19 00:30:56 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
impl OutgoingMessageSender {
|
|
|
|
|
pub(crate) fn new(sender: mpsc::Sender<OutgoingMessage>) -> Self {
|
|
|
|
|
Self {
|
|
|
|
|
next_request_id: AtomicI64::new(0),
|
|
|
|
|
sender,
|
2025-07-19 01:32:03 -04:00
|
|
|
request_id_to_callback: Mutex::new(HashMap::new()),
|
chore: introduce OutgoingMessageSender (#1622)
Previous to this change, `MessageProcessor` had a
`tokio::sync::mpsc::Sender<JSONRPCMessage>` as an abstraction for server
code to send a message down to the MCP client. Because `Sender` is cheap
to `clone()`, it was straightforward to make it available to tasks
scheduled with `tokio::task::spawn()`.
This worked well when we were only sending notifications or responses
back down to the client, but we want to add support for sending
elicitations in #1623, which means that we need to be able to send
_requests_ to the client, and now we need a bit of centralization to
ensure all request ids are unique.
To that end, this PR introduces `OutgoingMessageSender`, which houses
the existing `Sender<OutgoingMessage>` as well as an `AtomicI64` to mint
out new, unique request ids. It has methods like `send_request()` and
`send_response()` so that callers do not have to deal with
`JSONRPCMessage` directly, as having to set the `jsonrpc` for each
message was a bit tedious (this cleans up `codex_tool_runner.rs` quite a
bit).
We do not have `OutgoingMessageSender` implement `Clone` because it is
important that the `AtomicI64` is shared across all users of
`OutgoingMessageSender`. As such, `Arc<OutgoingMessageSender>` must be
used instead, as it is frequently shared with new tokio tasks.
As part of this change, we update `message_processor.rs` to embrace
`await`, though we must be careful that no individual handler blocks the
main loop and prevents other messages from being handled.
---
[//]: # (BEGIN SAPLING FOOTER)
Stack created with [Sapling](https://sapling-scm.com). Best reviewed
with [ReviewStack](https://reviewstack.dev/openai/codex/pull/1622).
* #1623
* __->__ #1622
* #1621
* #1620
2025-07-19 00:30:56 -04:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2025-07-19 01:32:03 -04:00
|
|
|
pub(crate) async fn send_request(
|
|
|
|
|
&self,
|
|
|
|
|
method: &str,
|
|
|
|
|
params: Option<serde_json::Value>,
|
|
|
|
|
) -> oneshot::Receiver<Result> {
|
|
|
|
|
let id = RequestId::Integer(self.next_request_id.fetch_add(1, Ordering::Relaxed));
|
|
|
|
|
let outgoing_message_id = id.clone();
|
|
|
|
|
let (tx_approve, rx_approve) = oneshot::channel();
|
|
|
|
|
{
|
|
|
|
|
let mut request_id_to_callback = self.request_id_to_callback.lock().await;
|
|
|
|
|
request_id_to_callback.insert(id, tx_approve);
|
|
|
|
|
}
|
|
|
|
|
|
chore: introduce OutgoingMessageSender (#1622)
Previous to this change, `MessageProcessor` had a
`tokio::sync::mpsc::Sender<JSONRPCMessage>` as an abstraction for server
code to send a message down to the MCP client. Because `Sender` is cheap
to `clone()`, it was straightforward to make it available to tasks
scheduled with `tokio::task::spawn()`.
This worked well when we were only sending notifications or responses
back down to the client, but we want to add support for sending
elicitations in #1623, which means that we need to be able to send
_requests_ to the client, and now we need a bit of centralization to
ensure all request ids are unique.
To that end, this PR introduces `OutgoingMessageSender`, which houses
the existing `Sender<OutgoingMessage>` as well as an `AtomicI64` to mint
out new, unique request ids. It has methods like `send_request()` and
`send_response()` so that callers do not have to deal with
`JSONRPCMessage` directly, as having to set the `jsonrpc` for each
message was a bit tedious (this cleans up `codex_tool_runner.rs` quite a
bit).
We do not have `OutgoingMessageSender` implement `Clone` because it is
important that the `AtomicI64` is shared across all users of
`OutgoingMessageSender`. As such, `Arc<OutgoingMessageSender>` must be
used instead, as it is frequently shared with new tokio tasks.
As part of this change, we update `message_processor.rs` to embrace
`await`, though we must be careful that no individual handler blocks the
main loop and prevents other messages from being handled.
---
[//]: # (BEGIN SAPLING FOOTER)
Stack created with [Sapling](https://sapling-scm.com). Best reviewed
with [ReviewStack](https://reviewstack.dev/openai/codex/pull/1622).
* #1623
* __->__ #1622
* #1621
* #1620
2025-07-19 00:30:56 -04:00
|
|
|
let outgoing_message = OutgoingMessage::Request(OutgoingRequest {
|
2025-07-19 01:32:03 -04:00
|
|
|
id: outgoing_message_id,
|
chore: introduce OutgoingMessageSender (#1622)
Previous to this change, `MessageProcessor` had a
`tokio::sync::mpsc::Sender<JSONRPCMessage>` as an abstraction for server
code to send a message down to the MCP client. Because `Sender` is cheap
to `clone()`, it was straightforward to make it available to tasks
scheduled with `tokio::task::spawn()`.
This worked well when we were only sending notifications or responses
back down to the client, but we want to add support for sending
elicitations in #1623, which means that we need to be able to send
_requests_ to the client, and now we need a bit of centralization to
ensure all request ids are unique.
To that end, this PR introduces `OutgoingMessageSender`, which houses
the existing `Sender<OutgoingMessage>` as well as an `AtomicI64` to mint
out new, unique request ids. It has methods like `send_request()` and
`send_response()` so that callers do not have to deal with
`JSONRPCMessage` directly, as having to set the `jsonrpc` for each
message was a bit tedious (this cleans up `codex_tool_runner.rs` quite a
bit).
We do not have `OutgoingMessageSender` implement `Clone` because it is
important that the `AtomicI64` is shared across all users of
`OutgoingMessageSender`. As such, `Arc<OutgoingMessageSender>` must be
used instead, as it is frequently shared with new tokio tasks.
As part of this change, we update `message_processor.rs` to embrace
`await`, though we must be careful that no individual handler blocks the
main loop and prevents other messages from being handled.
---
[//]: # (BEGIN SAPLING FOOTER)
Stack created with [Sapling](https://sapling-scm.com). Best reviewed
with [ReviewStack](https://reviewstack.dev/openai/codex/pull/1622).
* #1623
* __->__ #1622
* #1621
* #1620
2025-07-19 00:30:56 -04:00
|
|
|
method: method.to_string(),
|
|
|
|
|
params,
|
|
|
|
|
});
|
|
|
|
|
let _ = self.sender.send(outgoing_message).await;
|
2025-07-19 01:32:03 -04:00
|
|
|
rx_approve
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub(crate) async fn notify_client_response(&self, id: RequestId, result: Result) {
|
|
|
|
|
let entry = {
|
|
|
|
|
let mut request_id_to_callback = self.request_id_to_callback.lock().await;
|
|
|
|
|
request_id_to_callback.remove_entry(&id)
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
match entry {
|
|
|
|
|
Some((id, sender)) => {
|
|
|
|
|
if let Err(err) = sender.send(result) {
|
|
|
|
|
warn!("could not notify callback for {id:?} due to: {err:?}");
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
None => {
|
|
|
|
|
warn!("could not find callback for {id:?}");
|
|
|
|
|
}
|
|
|
|
|
}
|
chore: introduce OutgoingMessageSender (#1622)
Previous to this change, `MessageProcessor` had a
`tokio::sync::mpsc::Sender<JSONRPCMessage>` as an abstraction for server
code to send a message down to the MCP client. Because `Sender` is cheap
to `clone()`, it was straightforward to make it available to tasks
scheduled with `tokio::task::spawn()`.
This worked well when we were only sending notifications or responses
back down to the client, but we want to add support for sending
elicitations in #1623, which means that we need to be able to send
_requests_ to the client, and now we need a bit of centralization to
ensure all request ids are unique.
To that end, this PR introduces `OutgoingMessageSender`, which houses
the existing `Sender<OutgoingMessage>` as well as an `AtomicI64` to mint
out new, unique request ids. It has methods like `send_request()` and
`send_response()` so that callers do not have to deal with
`JSONRPCMessage` directly, as having to set the `jsonrpc` for each
message was a bit tedious (this cleans up `codex_tool_runner.rs` quite a
bit).
We do not have `OutgoingMessageSender` implement `Clone` because it is
important that the `AtomicI64` is shared across all users of
`OutgoingMessageSender`. As such, `Arc<OutgoingMessageSender>` must be
used instead, as it is frequently shared with new tokio tasks.
As part of this change, we update `message_processor.rs` to embrace
`await`, though we must be careful that no individual handler blocks the
main loop and prevents other messages from being handled.
---
[//]: # (BEGIN SAPLING FOOTER)
Stack created with [Sapling](https://sapling-scm.com). Best reviewed
with [ReviewStack](https://reviewstack.dev/openai/codex/pull/1622).
* #1623
* __->__ #1622
* #1621
* #1620
2025-07-19 00:30:56 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub(crate) async fn send_response(&self, id: RequestId, result: Result) {
|
|
|
|
|
let outgoing_message = OutgoingMessage::Response(OutgoingResponse { id, result });
|
|
|
|
|
let _ = self.sender.send(outgoing_message).await;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub(crate) async fn send_event_as_notification(&self, event: &Event) {
|
|
|
|
|
#[expect(clippy::expect_used)]
|
|
|
|
|
let params = Some(serde_json::to_value(event).expect("Event must serialize"));
|
|
|
|
|
let outgoing_message = OutgoingMessage::Notification(OutgoingNotification {
|
|
|
|
|
method: "codex/event".to_string(),
|
2025-07-26 10:35:49 -07:00
|
|
|
params: params.clone(),
|
|
|
|
|
});
|
|
|
|
|
let _ = self.sender.send(outgoing_message).await;
|
|
|
|
|
|
|
|
|
|
self.send_event_as_notification_new_schema(event, params)
|
|
|
|
|
.await;
|
|
|
|
|
}
|
|
|
|
|
// should be backwards compatible.
|
|
|
|
|
// it will replace send_event_as_notification eventually.
|
|
|
|
|
async fn send_event_as_notification_new_schema(
|
|
|
|
|
&self,
|
|
|
|
|
event: &Event,
|
|
|
|
|
params: Option<serde_json::Value>,
|
|
|
|
|
) {
|
|
|
|
|
let outgoing_message = OutgoingMessage::Notification(OutgoingNotification {
|
|
|
|
|
method: event.msg.to_string(),
|
chore: introduce OutgoingMessageSender (#1622)
Previous to this change, `MessageProcessor` had a
`tokio::sync::mpsc::Sender<JSONRPCMessage>` as an abstraction for server
code to send a message down to the MCP client. Because `Sender` is cheap
to `clone()`, it was straightforward to make it available to tasks
scheduled with `tokio::task::spawn()`.
This worked well when we were only sending notifications or responses
back down to the client, but we want to add support for sending
elicitations in #1623, which means that we need to be able to send
_requests_ to the client, and now we need a bit of centralization to
ensure all request ids are unique.
To that end, this PR introduces `OutgoingMessageSender`, which houses
the existing `Sender<OutgoingMessage>` as well as an `AtomicI64` to mint
out new, unique request ids. It has methods like `send_request()` and
`send_response()` so that callers do not have to deal with
`JSONRPCMessage` directly, as having to set the `jsonrpc` for each
message was a bit tedious (this cleans up `codex_tool_runner.rs` quite a
bit).
We do not have `OutgoingMessageSender` implement `Clone` because it is
important that the `AtomicI64` is shared across all users of
`OutgoingMessageSender`. As such, `Arc<OutgoingMessageSender>` must be
used instead, as it is frequently shared with new tokio tasks.
As part of this change, we update `message_processor.rs` to embrace
`await`, though we must be careful that no individual handler blocks the
main loop and prevents other messages from being handled.
---
[//]: # (BEGIN SAPLING FOOTER)
Stack created with [Sapling](https://sapling-scm.com). Best reviewed
with [ReviewStack](https://reviewstack.dev/openai/codex/pull/1622).
* #1623
* __->__ #1622
* #1621
* #1620
2025-07-19 00:30:56 -04:00
|
|
|
params,
|
|
|
|
|
});
|
|
|
|
|
let _ = self.sender.send(outgoing_message).await;
|
|
|
|
|
}
|
|
|
|
|
pub(crate) async fn send_error(&self, id: RequestId, error: JSONRPCErrorError) {
|
|
|
|
|
let outgoing_message = OutgoingMessage::Error(OutgoingError { id, error });
|
|
|
|
|
let _ = self.sender.send(outgoing_message).await;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// Outgoing message from the server to the client.
|
|
|
|
|
pub(crate) enum OutgoingMessage {
|
|
|
|
|
Request(OutgoingRequest),
|
|
|
|
|
Notification(OutgoingNotification),
|
|
|
|
|
Response(OutgoingResponse),
|
|
|
|
|
Error(OutgoingError),
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
impl From<OutgoingMessage> for JSONRPCMessage {
|
|
|
|
|
fn from(val: OutgoingMessage) -> Self {
|
|
|
|
|
use OutgoingMessage::*;
|
|
|
|
|
match val {
|
|
|
|
|
Request(OutgoingRequest { id, method, params }) => {
|
|
|
|
|
JSONRPCMessage::Request(JSONRPCRequest {
|
|
|
|
|
jsonrpc: JSONRPC_VERSION.into(),
|
|
|
|
|
id,
|
|
|
|
|
method,
|
|
|
|
|
params,
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
Notification(OutgoingNotification { method, params }) => {
|
|
|
|
|
JSONRPCMessage::Notification(JSONRPCNotification {
|
|
|
|
|
jsonrpc: JSONRPC_VERSION.into(),
|
|
|
|
|
method,
|
|
|
|
|
params,
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
Response(OutgoingResponse { id, result }) => {
|
|
|
|
|
JSONRPCMessage::Response(JSONRPCResponse {
|
|
|
|
|
jsonrpc: JSONRPC_VERSION.into(),
|
|
|
|
|
id,
|
|
|
|
|
result,
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
Error(OutgoingError { id, error }) => JSONRPCMessage::Error(JSONRPCError {
|
|
|
|
|
jsonrpc: JSONRPC_VERSION.into(),
|
|
|
|
|
id,
|
|
|
|
|
error,
|
|
|
|
|
}),
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#[derive(Debug, Clone, PartialEq, Serialize)]
|
|
|
|
|
pub(crate) struct OutgoingRequest {
|
|
|
|
|
pub id: RequestId,
|
|
|
|
|
pub method: String,
|
|
|
|
|
#[serde(default, skip_serializing_if = "Option::is_none")]
|
|
|
|
|
pub params: Option<serde_json::Value>,
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#[derive(Debug, Clone, PartialEq, Serialize)]
|
|
|
|
|
pub(crate) struct OutgoingNotification {
|
|
|
|
|
pub method: String,
|
|
|
|
|
#[serde(default, skip_serializing_if = "Option::is_none")]
|
|
|
|
|
pub params: Option<serde_json::Value>,
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#[derive(Debug, Clone, PartialEq, Serialize)]
|
|
|
|
|
pub(crate) struct OutgoingResponse {
|
|
|
|
|
pub id: RequestId,
|
|
|
|
|
pub result: Result,
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#[derive(Debug, Clone, PartialEq, Serialize)]
|
|
|
|
|
pub(crate) struct OutgoingError {
|
|
|
|
|
pub error: JSONRPCErrorError,
|
|
|
|
|
pub id: RequestId,
|
|
|
|
|
}
|