Replace stale RPC transaction and event retention guidance (#2595) (#2656)

stellar-rpc retired the time-based `transaction-retention-window` setting in
favor of a single ledger-denominated `history-retention-window` covering both
transactions and events, with a stock default of 120960 ledgers (~7 days).
The docs still described a 24-hour default and a separate seven-day cap.

- getTransaction.mdx and the getTransaction/getEvents openrpc method
  descriptions now describe the ledger-count window, its 120960 default, and
  how to inspect the live window via getHealth (ledgerRetentionWindow,
  oldestLedger, latestLedger); regenerated static/stellar-rpc.openrpc.json
- softened the RPC README "maximum 7 days" line to a bounded default window

Verified against stellar-rpc source and live getHealth on testnet + mainnet.

Closes #2595

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: ElliotFriend

docs/data/apis/rpc/README.mdx

@@ -27,7 +27,7 @@ Running RPC within your own infrastructure provides a number of benefits. You ca
 
 What Stellar RPC is not:
 
-- An indexer for historical data. RPC retains at maximum 7 days of historical data.
+- An indexer for historical data. RPC retains only a bounded, recent window of history (about 7 days by default).
 - A primary backend service for your application. Use RPC as your gateway to the blockchain, but ingest and index only the data you care about.
 - A drop-in replacement for Horizon. Horizon provides several indexing features not commonly supported by RPC nodes. We believe these business opportunities should be passed back to third party applications (indexers, analytics providers, etc) and away from the SDF.
 

docs/data/apis/rpc/api-reference/methods/getTransaction.mdx

@@ -79,7 +79,7 @@ public class GetTransactionExample {
 
 You can use the `getTransaction` method in the [Stellar Laboratory](https://laboratory.stellar.org) to **retrieve details about a specific transaction**. This is especially useful for checking the status of a transaction to determine whether it has been successfully recorded on the blockchain.
 
-The **default transaction history retention window** in `stellar-rpc` is **24 hours**, but this can be adjusted (up to 7 days) for private Soroban RPC instances using the `transaction-retention-window` configuration setting. For transaction debugging beyond that window, consider indexing the data yourself, using a third-party indexer, or querying **Hubble**—Stellar’s public BigQuery dataset.
+`stellar-rpc` retains a bounded, ledger-denominated history of recent transactions and events, configured by a single `history-retention-window` setting. The stock default is **120960 ledgers** (about **7 days**, depending on ledger cadence), and operators of private instances can adjust it. You can inspect the active window and the range of ledgers available on an instance with the [`getHealth`](./getHealth.mdx) method (`ledgerRetentionWindow`, `oldestLedger`, `latestLedger`). For transaction debugging beyond the retained window, consider indexing the data yourself, using a third-party indexer, or querying **Hubble**—Stellar’s public BigQuery dataset.
 
 👉 [View getTransaction on the Lab](https://lab.stellar.org/endpoints/rpc/get-transaction?$=network$id=testnet&label=Testnet&horizonUrl=https:////horizon-testnet.stellar.org&rpcUrl=https:////soroban-testnet.stellar.org&passphrase=Test%20SDF%20Network%20/;%20September%202015;;)
 

openrpc/src/stellar-rpc/methods/getEvents.json

@@ -1,7 +1,7 @@
 {
     "name": "getEvents",
     "summary": "returns contract events",
-    "description": "Clients can request a filtered list of events emitted by a given ledger range.\n\nStellar-RPC will support querying within a maximum 7 days of recent ledgers.\n\nNote, this could be used by the client to only prompt a refresh when there is a new ledger with relevant events. It should also be used by backend Dapp components to \"ingest\" events into their own database for querying and serving.\n\nIf making multiple requests, clients should deduplicate any events received, based on the event's unique id field. This prevents double-processing in the case of duplicate events being received.\n\nBy default stellar-rpc retains the most recent 24 hours of events.",
+    "description": "Clients can request a filtered list of events emitted by a given ledger range.\n\nStellar-RPC retains a bounded, ledger-denominated history of recent transactions and events, configured by a single history-retention-window setting with a stock default of 120960 ledgers (about 7 days, depending on ledger cadence); requests are served from within that retained range. The effective window and the ledgers currently available can be inspected via the getHealth method (ledgerRetentionWindow, oldestLedger, latestLedger).\n\nNote, this could be used by the client to only prompt a refresh when there is a new ledger with relevant events. It should also be used by backend Dapp components to \"ingest\" events into their own database for querying and serving.\n\nIf making multiple requests, clients should deduplicate any events received, based on the event's unique id field. This prevents double-processing in the case of duplicate events being received.",
     "externalDocs": {
         "url": "https://developers.stellar.org/docs/data/apis/rpc/api-reference/methods/getEvents"
     },

openrpc/src/stellar-rpc/methods/getTransaction.json

@@ -1,7 +1,7 @@
 {
     "name": "getTransaction",
     "summary": "returns transaction details",
-    "description": "The getTransaction method provides details about the specified transaction. Clients are expected to periodically query this method to ascertain when a transaction has been successfully recorded on the blockchain. The stellar-rpc system maintains a restricted history of recently processed transactions, with the default retention window set at 24 hours. For private soroban-rpc instances, it is possible to modify the retention window value by adjusting the transaction-retention-window configuration setting, but we do not recommend values longer than 7 days. For debugging needs that extend beyond this timeframe, it is advisable to index this data yourself, employ a third-party [indexer](https://developers.stellar.org/docs/tools/developer-tools/data-indexers), or query [Hubble](https://developers.stellar.org/docs/data/hubble) (our public BigQuery data set).",
+    "description": "The getTransaction method provides details about the specified transaction. Clients are expected to periodically query this method to ascertain when a transaction has been successfully recorded on the blockchain. The stellar-rpc system maintains a bounded history of recently processed transactions and events, configured by a single history-retention-window setting expressed in ledgers, with a stock default of 120960 ledgers (about 7 days, depending on ledger cadence). Operators of private stellar-rpc instances can adjust this value. The effective time span and the range of ledgers currently available can be inspected via the getHealth method (ledgerRetentionWindow, oldestLedger, latestLedger). For debugging needs that extend beyond the retained window, it is advisable to index this data yourself, employ a third-party [indexer](https://developers.stellar.org/docs/tools/developer-tools/data-indexers), or query [Hubble](https://developers.stellar.org/docs/data/hubble) (our public BigQuery data set).",
     "externalDocs": {
         "url": "https://developers.stellar.org/docs/data/apis/rpc/api-reference/methods/getTransaction"
     },

static/stellar-rpc.openrpc.json

@@ -33,7 +33,7 @@
     {
       "name": "getEvents",
       "summary": "returns contract events",
-      "description": "Clients can request a filtered list of events emitted by a given ledger range.\n\nStellar-RPC will support querying within a maximum 7 days of recent ledgers.\n\nNote, this could be used by the client to only prompt a refresh when there is a new ledger with relevant events. It should also be used by backend Dapp components to \"ingest\" events into their own database for querying and serving.\n\nIf making multiple requests, clients should deduplicate any events received, based on the event's unique id field. This prevents double-processing in the case of duplicate events being received.\n\nBy default stellar-rpc retains the most recent 24 hours of events.",
+      "description": "Clients can request a filtered list of events emitted by a given ledger range.\n\nStellar-RPC retains a bounded, ledger-denominated history of recent transactions and events, configured by a single history-retention-window setting with a stock default of 120960 ledgers (about 7 days, depending on ledger cadence); requests are served from within that retained range. The effective window and the ledgers currently available can be inspected via the getHealth method (ledgerRetentionWindow, oldestLedger, latestLedger).\n\nNote, this could be used by the client to only prompt a refresh when there is a new ledger with relevant events. It should also be used by backend Dapp components to \"ingest\" events into their own database for querying and serving.\n\nIf making multiple requests, clients should deduplicate any events received, based on the event's unique id field. This prevents double-processing in the case of duplicate events being received.",
       "externalDocs": {
         "url": "https://developers.stellar.org/docs/data/apis/rpc/api-reference/methods/getEvents"
       },
@@ -1094,7 +1094,7 @@
     {
       "name": "getTransaction",
       "summary": "returns transaction details",
-      "description": "The getTransaction method provides details about the specified transaction. Clients are expected to periodically query this method to ascertain when a transaction has been successfully recorded on the blockchain. The stellar-rpc system maintains a restricted history of recently processed transactions, with the default retention window set at 24 hours. For private soroban-rpc instances, it is possible to modify the retention window value by adjusting the transaction-retention-window configuration setting, but we do not recommend values longer than 7 days. For debugging needs that extend beyond this timeframe, it is advisable to index this data yourself, employ a third-party [indexer](https://developers.stellar.org/docs/tools/developer-tools/data-indexers), or query [Hubble](https://developers.stellar.org/docs/data/hubble) (our public BigQuery data set).",
+      "description": "The getTransaction method provides details about the specified transaction. Clients are expected to periodically query this method to ascertain when a transaction has been successfully recorded on the blockchain. The stellar-rpc system maintains a bounded history of recently processed transactions and events, configured by a single history-retention-window setting expressed in ledgers, with a stock default of 120960 ledgers (about 7 days, depending on ledger cadence). Operators of private stellar-rpc instances can adjust this value. The effective time span and the range of ledgers currently available can be inspected via the getHealth method (ledgerRetentionWindow, oldestLedger, latestLedger). For debugging needs that extend beyond the retained window, it is advisable to index this data yourself, employ a third-party [indexer](https://developers.stellar.org/docs/tools/developer-tools/data-indexers), or query [Hubble](https://developers.stellar.org/docs/data/hubble) (our public BigQuery data set).",
       "externalDocs": {
         "url": "https://developers.stellar.org/docs/data/apis/rpc/api-reference/methods/getTransaction"
       },