Order websocket initialize after handshake (#13943)

## What changed
- `app-server` now sends initialize notifications to the specific
websocket connection before that connection is marked outbound-ready.
- `message_processor` now exposes the forwarding hook needed to target
that initialize delivery path.

## Why this fixes the flake
- This was a real websocket ordering bug.
- The old code allowed “connection is ready for outbound broadcasts” to
become true before the initialize notification had been routed to the
intended client.
- On CI this showed up as a race where tests would occasionally miss or
misorder initialize delivery depending on scheduler timing.
- Sending initialize to the exact connection first, then exposing it to
the general outbound path, removes that race instead of hiding it with
timing slack.

## Scope
- Production logic change.
This commit is contained in:
Ahmed Ibrahim authored and GitHub committed 2026-03-09 10:27:19 -07:00
1 parent 6b68d1ef66
commit 0dc242a672
2 files changed
+52 -17

No files matched your search

+9 -2
View File
@@ -715,7 +715,6 @@ pub async fn run_main_with_transport(
request,
transport,
&mut connection_state.session,
&connection_state.outbound_initialized,
)
.await;
if let Ok(mut opted_out_notification_methods) = connection_state
@@ -738,7 +737,15 @@ pub async fn run_main_with_transport(
std::sync::atomic::Ordering::Release,
);
if !was_initialized && connection_state.session.initialized {
processor.send_initialize_notifications().await;
processor
.send_initialize_notifications_to_connection(
connection_id,
)
.await;
processor.connection_initialized(connection_id).await;
connection_state
.outbound_initialized
.store(true, std::sync::atomic::Ordering::Release);
}
}
JSONRPCMessage::Response(response) => {