[docs-agent] Add Yellowstone gRPC historical replay page#1474
[docs-agent] Add Yellowstone gRPC historical replay page#1474alchemy-bot wants to merge 2 commits into
Conversation
Adds a new page under Yellowstone gRPC → Getting Started documenting the historical replay feature (up to 6000 slots / ~40 minutes of backfill). Modeled off Helius LaserStream's historical replay page with Alchemy-specific window, endpoint, and Rust code samples. Refs DOCS-157 Requested-by: @clinder777
🔗 Preview Mode
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 75075f847b
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| // In production, fetch the current slot via getSlot and subtract however | ||
| // many slots back you want to replay (for example, current_slot - 1000 | ||
| // rewinds ~7 minutes). | ||
| let from_slot: u64 = 419_800_000; |
There was a problem hiding this comment.
Avoid using a fixed from_slot in the quickstart
Because historical replay only accepts slots within the ~6000-slot (~40 minute) replay window, this hard-coded absolute mainnet slot ages out almost immediately; after that, readers who copy the quickstart will get the request rejected before streaming any data. Derive from_slot from the current getSlot result (or leave it as a placeholder expression) instead of publishing a fixed slot value.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Good catch — applied in c2a7a18. Rewrote the quickstart to call getSlot first and rewind ~1000 slots (~7 minutes), matching the pattern the accordion examples below already use. The intro paragraph now explicitly says to avoid hard-coding an absolute slot value. Also renamed the local variable from x_token to api_key so it's clear the same value serves both the gRPC X-Token header and the getSlot HTTP call.
…Slot The quickstart hard-coded from_slot = 419_800_000, but historical replay only accepts slots inside the ~6000 slot (~40 minute) window, so any absolute value ages out almost immediately. Rewrite the quickstart to call getSlot first and rewind ~1000 slots (~7 minutes), matching the pattern already shown in the accordion examples below. Also rename the local variable from x_token to api_key so it's clear the value is reused for both the gRPC X-Token header and the getSlot HTTP call. Addresses codex P2 feedback on PR #1474. Refs DOCS-157 Requested-by: @clinder777
Summary
Adds a new Historical Replay page under Yellowstone gRPC → Getting Started documenting how to backfill missing Solana data with the
from_slotfield onSubscribeRequest.The page is modeled on Helius LaserStream's historical replay page but uses Alchemy-specific details throughout:
overview.mdxandsubscribe-request.mdx); Helius's page cites 216,000 slots / 24h.from_slot(protobuf snake_case), notfromSlot.https://solana-mainnet.g.alchemy.comwith theX-Tokenauth header, and code samples are Rust to match the rest of the Yellowstone section.Files
content/api-reference/yellowstone/historical-replay.mdx(new)content/docs.yml— new page entry under Yellowstone gRPC → Getting Started (between Quickstart and the API Reference sub-section)Sections on the new page
from_slot)from_slotfield details, with cross-link to the Subscribe request referenceLinear
DOCS-157 — https://linear.app/alchemyapi/issue/DOCS-157/add-yellowstone-grpc-historical-replay-page
Requested by
@clinder777 (via Slack thread)