Skip to content

[Rust] Reset ack timeout on progress - #792

Open
zlata-stefanovic-db wants to merge 1 commit into
mainfrom
fix/rust-lack-of-ack-progress
Open

[Rust] Reset ack timeout on progress#792
zlata-stefanovic-db wants to merge 1 commit into
mainfrom
fix/rust-lack-of-ack-progress

Conversation

@zlata-stefanovic-db

Copy link
Copy Markdown
Contributor

What changes are proposed in this pull request?

Fixes #639.

The gRPC receiver used a per-read timeout around every inbound frame. Any message reset the lack-of-ack clock, including a stale or duplicate durability_ack_up_to_offset that did not advance durability. A server repeating the same ack could postpone recovery indefinitely while later offsets stayed unacknowledged.

This PR keeps one deadline and moves it only when the ack watermark advances. Duplicate/stale acks and other frames no longer extend the budget.

How is this tested?

  • cargo test -p databricks-zerobus-ingest-sdk
  • cargo test -p tests --test rust_tests
  • New regression: test_duplicate_acks_do_not_reset_server_ack_timeout dribbles duplicate acks every 50ms and asserts the stream still fails with Server ack timeout within one timeout window.

Duplicate or stale acks no longer postpone recovery.

Signed-off-by: Zlata Stefanovic <zlata.stefanovic@databricks.com>
@zlata-stefanovic-db
zlata-stefanovic-db marked this pull request as ready for review August 28, 2026 13:29
@zlata-stefanovic-db
zlata-stefanovic-db requested a review from a team August 28, 2026 13:29
@zlata-stefanovic-db zlata-stefanovic-db self-assigned this Aug 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Rust] Lack-of-ack timeout resets on any frame, not on durable progress

1 participant