Repository navigation
Conversation
…4/s14-awaited-publish
…4/s14-awaited-publish
Owner
Author
|
Review fix in 4698c5f: a |
…4/s14-awaited-publish
…4/s14-awaited-publish
…4/s14-awaited-publish
…4/s14-awaited-publish
Owner
Author
|
Closing as stale. This layer is folded into the v5 tip, #41, and the upstream review uses a fresh series instead. Plan: https://www.notion.so/4048fc567738814990b7c796ac28fe3f |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed?
This PR adds the extension call
WriteRecords, the awaited publish of an Activity or a client.WriteRecordsRequest { writer_id, records }appends the Records at once for an open writer and answersWriteRecordsResponse { first_offset, last_offset }when they are in the Store. It first sends whatPublishbuffered, under the same flush lock, so the order of one writer holds. It keeps the writer's Producer epoch andsequenceorder. A Store failure resends the same batch with the samesequence, so a batch whose answer was lost goes in once. Records past the Store's batch size or byte limit go as more batches, in order, and the offsets span all of them. An empty request answers zeros with no write.A Record over the Store's Record limit, or a closed writer, is refused before the Store, and the writer stays usable after the size refusal. A failure after the Store retries fails the writer, as a failed flush does, since the batch may be in the Store.
I chose to keep
Publishand the interval writer for compatibility. An SDK does not need them for an awaited publish: it opens a writer per Producer epoch (which still sends the empty batch of an Activity retry), callsWriteRecordsper publish, andCloseWriterat the end.BufferedPublisherin lang can sit onWriteRecordswith its own timer.Why?
Decision S71 (and S47). An Activity or client
await publishmust have published when it returns, and it returns the offset. A hidden timer would make the return mean only "buffered".How did you test it?
cargo fmt --all -- --check,cargo clippy --workspace --tests -- -D warnings(also with--no-default-features --features tls-aws-lc), andSTREAMS_REQUIRE=redis cargo test --workspaceon standalone Redis, a 3-primary Redis cluster and the memory Store.New writer tests check that a write is readable when it answers and that its offsets match, that a write goes after buffered Records in one order and splits at the batch size, that an Activity retry's write withdraws the earlier attempt and fences it, and the refusals of an oversize Record and a closed writer. A test on a memory Store that loses the first append answer checks that the retry goes in once with the first offsets.