magicblock-grpc-example

Minimal reproduction for a MagicBlock Ephemeral Rollup gRPC (Yellowstone / Geyser) subscription that connects successfully but never delivers account updates.

This was extracted from the production subscriber in flash-ui-api-rust (src/magicblock/ingestion/grpc.rs) with all application state and decoding stripped out — it is only the bits needed to reproduce the issue.

The issue

1. The client connects to the MagicBlock ER gRPC endpoint without errors.
2. subscribe_with_request returns a stream successfully.
3. Ping frames arrive as expected (~every 10s) and are acked — so the transport itself is alive and the subscription is open end-to-end.
4. But no Account updates ever arrive over that stream, even though the same program actively receives account writes on the ER (confirmed via JSON-RPC getProgramAccounts against the same endpoint, which returns and updates accounts as expected).

Testing is done against devnet (https://devnet-as.magicblock.app).

What it does

• Opens a single gRPC subscription to the endpoint.
• Filters for account updates where owner == <program_id>.
• Commitment: Confirmed.
• Logs every Account, Ping, and Pong update it receives, plus a running counter, so you can tell immediately whether anything is arriving.
• On disconnect / error, reconnects every 5s.

Default configuration

Variable	Default
MB_GRPC_ENDPOINT	https://devnet-as.magicblock.app
MB_PROGRAM_ID	FMTgsEDaPPfJi1PKD67McLTC5n833T4irbBP53LLxtvj
RUST_LOG	info (set to debug or trace for more detail)

All are optional — running cargo run with no env vars hits devnet with the default Magic Trade program ID.

Run it

# default
cargo run --release

# custom endpoint / program
MB_GRPC_ENDPOINT=https://devnet-as.magicblock.app \
MB_PROGRAM_ID=FMTgsEDaPPfJi1PKD67McLTC5n833T4irbBP53LLxtvj \
RUST_LOG=debug \
cargo run --release

Expected vs actual output

Expected

INFO connecting to https://devnet-as.magicblock.app...
INFO connected — sending subscribe request
INFO subscription established — waiting for updates
INFO update #1 slot=123456 pubkey=... owner=FMTgsEDaPPfJi1PKD67McLTC5n833T4irbBP53LLxtvj lamports=... data_len=...
INFO update #2 slot=123457 pubkey=... ...
INFO ping #1 received — responding
INFO pong received
...

Actual

INFO connecting to https://devnet-as.magicblock.app...
INFO connected — sending subscribe request
INFO subscription established — waiting for updates
INFO ping #1 received — responding
INFO pong received
INFO ping #2 received — responding
INFO pong received
(pings arrive on schedule, but no account updates ever come)

Pings prove the stream is alive end-to-end — only the account notifications are missing.

Dependencies

• yellowstone-grpc-client = "11"
• yellowstone-grpc-proto = "11"
• tonic = "0.14" with zstd

These are the exact versions used in the production service where the issue was first observed.

Notes for the MagicBlock team

• The MagicBlock ER gRPC endpoint uses TLS but no auth token (unlike e.g. Shyft Yellowstone), so the client is built with only ClientTlsConfig::new().with_native_roots() and no x_token. If the endpoint now requires auth, that would explain the silence — please let us know the expected auth mechanism.
• The same process concurrently runs getProgramAccounts against the same host over JSON-RPC and sees fresh accounts, so the program is definitely active on the ER — the issue appears specific to the gRPC subscription path.
• The filter is by owner only (no account pubkey list, no memcmp filters). If MagicBlock's Geyser plugin requires a different filter shape (e.g. a non-empty account list, or filters entries), please advise.