Inconsistent 5-minute bar OHLCV data between real-time and historical queries for the same bar

[jwsher]

Describe the bug
5-minute bar data returned by the Historical Stock Bars API for a past date does not exactly match the data returned by the same API when called in real-time during market hours for that same bar. Specifically, the OHLCV values for the 15:50 (3:55 PM ET) 5-minute bar differ slightly between a real-time call and a subsequent historical call for the same symbol, date, and timeframe.

This suggests that bar data is being modified/finalized after it is initially served, without any documentation or versioning to indicate the data has changed.

To Reproduce

1. During market hours, call StockHistoricalDataClient.get_stock_bars() with TimeFrame(5, TimeFrameUnit.Minute) for a symbol (e.g., SYM, GLD) with start and end spanning the current
   trading day (9:30 AM_4:00 PM ET). Record the OHLCV values for the 15:50 bar.
2. After market close (or the next day), call the exact same endpoint with the exact same parameters for the same date.
3. Compare the OHLCV values from step 1 and step 2.
   Observed differences (March 4, 2026):
   | Symbol │ Field │ Real-time value │ Historical value │ Delta |
   │ SYM │ volume │ 638,298 │ 638,296 │ -2 │
   │ GLD │ high │ 476.42 │ 476.415 │ -0.005 │
   These are representative examples _ similar small discrepancies were observed across multiple symbols.

Expected behavior
Once a 5-minute bar's time window has closed (e.g., the 15:50 bar closes at 15:55:00), the OHLCV values returned by the API should be immutable. A historical query for that bar should return the exact same values that were served in real-time. If bars are subject to post-hoc corrections (e.g., late prints, exchange corrections), this should be documented and ideally indicated via a revision flag or timestamp.

Screenshots
N/A _ this is an API data consistency issue, not a UI issue.

Desktop (please complete the following information):

• OS: Ubuntu 22.04
• Language: Python 3.12
• SDK: alpaca-py (latest)
• API: Alpaca Data API v2, StockHistoricalDataClient

Additional context
If this behavior is totally unavoidable, maybe you could :

1. Document it (e.g., "bars may be adjusted for up to N minutes after close due to late prints")
2. Provide a is_final or revision field on bar responses
3. Offer a "final" feed option that waits for settlement before serving

Thanks!