The signed URL in this case creates a resumable upload session which are idempotent per session.

Creating a signed URL that can only be once would requirehttps://cloud.google.com/storage/docs/xml-api/reference-headers#xgoogifgenerationmatch with value 0 but it's possible that a session is created but not completed when this preconditions is checked which can't be helped.

If I'm understanding correctly, that if-generation-match header would be part of the signed URL and not something our client could be aware of. Meaning, our client doesn't have visibility into any precondition which might apply to the request.

oof, this is an interesting case; if a user generates a v4 signed url and adds this header as signed then our client tries to create a resumable upload; it will fail without this header in the request with the expected value.

Our client code could extract the header/values pairs from the signed URL, but sounds like a feature request.

Wouldn't this cause issues for customers that write data as it comes in (might be less than 256KiB) so buffer would be filled over multiple writes to perform a final flush on falling out of writer scope or explicitly flushing or close()?

Potentially in standalone yet, however customers are not interacting with this class directly themselves.

We have the following pipeline to usage of this class (bash pipeline shorthand):

BlobWriteChannelV2 | BaseStorageWriteChannel | DefaultBufferedWritableByteChannel | ApiaryUnbufferedWritableByteChannel                     ^-- buffer allocation and alignment happens here

Pinged you through chat; but what's the rationale for using multiple buffers versus one? A few reasons come to mind (easier to allocate smaller contiguous memory buffers, individual buffers can be passed as-is to transport writes); and wondering if there are others.

One big one for us specifically, is from the buffered to unbuffered layer, this enables the ability to reduce (and in some cases completely remove) copies between theByteBuffer provided to ourwrite method, and any underlying location it needs to be propagated to.

A codified test case that illustrates this minimized copying can be seen here:

In that test flushes will happen every 3 bytes, where we're doing 16 byte writes. In order to flush, we don't need to copy into our buffer, we can simply take a 3 byte slice of the providedByteBuffer and flush that. Then if there is any outstanding bytes they are enqueued. Then the next timewrite is called, in a single call we can flush our buffer and the slice from the newByteBuffer.