Summary

alloy_pubsub silently drops every notification when the server returns a subscription ID shorter than 32 bytes. The subscription itself is reported as successful, the WebSocket stream stays open, but subscribe_blocks().into_stream() never yields a single header.

This affects spec-compliant Ethereum nodes — the JSON-RPC subscription spec (eth eth_subscribe) does not constrain the subscription ID to a fixed width. Some providers (notably wss://ethereum-rpc.publicnode.com) return a 16-byte hex ID; alloy's subscribe_blocks() deserialises the response into FixedBytes<32>, which causes a key mismatch in the pubsub frontend's subscription registry.

Reproduction

// Cargo.toml
//   alloy   = { version = "2", features = ["full"] }
//   tokio   = { version = "1", features = ["full"] }
//   futures = "0.3"

use alloy::providers::{Provider, ProviderBuilder};
use alloy::transports::ws::WsConnect;
use futures::StreamExt;
use std::time::Duration;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let url = "wss://ethereum-rpc.publicnode.com";

    let provider = ProviderBuilder::new()
        .connect_ws(WsConnect::new(url))
        .await?;

    let sub = provider.subscribe_blocks().await?;
    let mut stream = sub.into_stream();

    println!("subscribed; waiting up to 60s for a header…");

    match tokio::time::timeout(Duration::from_secs(60), stream.next()).await {
        Ok(Some(header)) => println!("OK — got header {}", header.number),
        Ok(None)         => eprintln!("FAIL — stream closed without yielding"),
        Err(_)           => eprintln!("FAIL — no header received in 60s"),
    }
    Ok(())
}

Run with:

RUST_LOG=alloy=trace cargo run

websocat against the same endpoint receives eth_subscription notifications every ~12 s, confirming the endpoint is healthy and pushing data. Alchemy and Infura (which return 32-byte hex IDs) work correctly with the same code.

Expected behaviour

stream.next() yields a new header per block (~12 s on Ethereum mainnet).

Actual behaviour

stream.next() blocks forever; no headers are emitted.

Trace evidence

Subscription ID gets corrupted between the WS layer and the pubsub frontend:

The deserialize_response span shows the type alloy is forcing the response into:

"ty":"alloy_primitives::bits::fixed::FixedBytes<32>"

Lookup key (32-byte derived value) ≠ notification key (original 16-byte ID) → notifications are silently dropped.

Environment

• alloy: 2.0.4 (workspace dep alloy = { version = "2", features = ["full"] })
• rustc: 1.95.0 (59807616e 2026-04-14)
• OS: macOS 14 (arm64, Apple Silicon)
• Endpoint: wss://ethereum-rpc.publicnode.com

Possible direction

The subscription ID type in alloy_pubsub could be loosened from FixedBytes<32> (i.e. B256) to a SubscriptionId enum that accepts variable-length hex strings or numeric IDs — matching EthNotification::subscription which is already typed as a flexible Number / String variant.

Happy to PR if there's a preferred direction.