fix(storage): use server-reported size on stream reconnect to avoid duplicate writes#16115
fix(storage): use server-reported size on stream reconnect to avoid duplicate writes#16115v-pratap wants to merge 3 commits into
Conversation
There was a problem hiding this comment.
Code Review
This pull request updates the AsyncWriterConnectionResumedState class to extract the persisted offset directly from the first response's resource size or persisted size when resuming a write operation, falling back to the persisted state if neither is present. A corresponding unit test has also been added to verify this behavior. The review feedback suggests optimizing performance by using std::move to avoid copying the protobuf resource message when finalizing the object.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #16115 +/- ##
==========================================
- Coverage 92.71% 92.71% -0.01%
==========================================
Files 2353 2353
Lines 219274 219364 +90
==========================================
+ Hits 203303 203386 +83
- Misses 15971 15978 +7 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
…n write stream reconnects
8c001b7 to
ddfdfd6
Compare
| // Regular resume succeeded, object not finalized. Continue writing. | ||
| auto persisted_offset = absl::get<std::int64_t>(state); | ||
|
|
||
| auto checksums = impl_->PersistedChecksums(); |
There was a problem hiding this comment.
Do we need to update the checksum as well using the response sent by the server?
Problem: When the C++ SDK loses connection while writing to an appendable (Rapid) object and tries to reconnect, it sometimes sends data that the server has already received. This happens because the client was ignoring the current object size reported by the server during the reconnect, and instead relied on its own older progress information saved before the connection dropped. This caused the server to reject the writes as out-of-range.
Solution: Modified the client to check the server's response immediately after reconnecting. If the server returns the current size of the object (and a handle to continue writing), the client now uses that size as the starting offset for sending new data. This prevents the client from re-sending data that the server already has.