Repository navigation
fix(storage): omit undefined limit and offset from listBuckets query - #2781
prestonschlagheck wants to merge 1 commit into
Conversation
|
Important Review skippedReview was skipped as selected files did not have any reviewable changes. ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Summary
Priority: ⬇️ Low Change: Bug fix Merge Risk: ⚪ Minimal · up to
|
listBuckets checked `'limit' in options` / `'offset' in options`, so a key
that was present but undefined (e.g. `listBuckets({ limit: pageSize })` with
no page size set) was sent as the literal string `limit=undefined`. Check for
`!== undefined` instead, matching StorageAnalyticsClient.listBuckets; `0` is
still sent.
f5afba4 to
5909d81
Compare
🔍 Description
What changed?
StorageBucketApi.listBucketsnow only addslimitandoffsetto the query string when they are defined. Before, it checked'limit' in options/'offset' in options.Why was this change needed?
A key can be present but
undefined. That happens with a common call likestorage.listBuckets({ limit: pageSize, offset })when the caller has no page size set. In that case the request was sent as:StorageAnalyticsClient.listBucketsalready uses!== undefinedfor the same options, so this makes the two consistent.0is still sent.📸 Screenshots/Examples
🔄 Breaking changes
📋 Checklist
<type>(<scope>): <description>pnpm nx formatto ensure consistent code formatting📝 Additional notes
Added two unit tests in
storageBucketApi.test.ts:limit/offsetare omitted. This test fails onmaster.limit: 0, offset: 0are still sent.The storage-js package compiles its tests with
exactOptionalPropertyTypes, so the first test casts its options to model a JS caller, or a TS caller without that flag.