Established while closing #166, in code that shipped before this milestone.
_scan_bucket in stdapi/batches.py walks the bucket ascending with MaxKeys=1000, keeps a trailing _LIST_SCAN_LIMIT (1,000) window, and stops after _LIST_SCAN_PAGES (100) pages. Past roughly 100,000 stored records the window is therefore taken from the oldest keys, and the most recent batches — the ones a client is actually listing for — are the ones missing.
Three related facts confirmed by the same investigation: every batch record goes to the single AWS_S3_BUCKET; that one window is shared with the Anthropic Message Batches surface, because _read_record filters by surface after the scan; and deleted records still occupy their slot in it.
#166 documented the limitation rather than fixing it — S3 cannot list backwards, so seeking the tail needs a key-space probe loop that could not be validated against real S3 from where that work was done. The limitation is now stated in docs/api_openai_batches.md and pinned by test_a_recent_batch_is_dropped_past_the_scan_page_budget, which fails if the page budget is lifted — so whoever fixes this will be told to delete the doc text.
Scope: make the listing window genuinely the most recent records, and delete the warning and the pinning test when it is.
Ref: stdapi/batches.py _scan_bucket, _LIST_SCAN_PAGES, _LIST_SCAN_LIMIT
Established while closing #166, in code that shipped before this milestone.
_scan_bucketinstdapi/batches.pywalks the bucket ascending withMaxKeys=1000, keeps a trailing_LIST_SCAN_LIMIT(1,000) window, and stops after_LIST_SCAN_PAGES(100) pages. Past roughly 100,000 stored records the window is therefore taken from the oldest keys, and the most recent batches — the ones a client is actually listing for — are the ones missing.Three related facts confirmed by the same investigation: every batch record goes to the single
AWS_S3_BUCKET; that one window is shared with the Anthropic Message Batches surface, because_read_recordfilters by surface after the scan; and deleted records still occupy their slot in it.#166 documented the limitation rather than fixing it — S3 cannot list backwards, so seeking the tail needs a key-space probe loop that could not be validated against real S3 from where that work was done. The limitation is now stated in
docs/api_openai_batches.mdand pinned bytest_a_recent_batch_is_dropped_past_the_scan_page_budget, which fails if the page budget is lifted — so whoever fixes this will be told to delete the doc text.Scope: make the listing window genuinely the most recent records, and delete the warning and the pinning test when it is.
Ref:
stdapi/batches.py_scan_bucket,_LIST_SCAN_PAGES,_LIST_SCAN_LIMIT