feat: end to end wiring for per message nack#365
Conversation
Signed-off-by: Abdullah Yildirim <a3hadi@protonmail.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #365 +/- ##
==========================================
+ Coverage 92.74% 92.94% +0.20%
==========================================
Files 67 68 +1
Lines 3540 3630 +90
Branches 232 234 +2
==========================================
+ Hits 3283 3374 +91
+ Misses 191 190 -1
Partials 66 66 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Signed-off-by: Abdullah Yildirim <a3hadi@protonmail.com>
| optional common.NackOptions nack_options = 2; | ||
| } | ||
| // Required field holding the request. The list will be ordered and will have the same order as the original Read response. | ||
| Request request = 1; |
There was a problem hiding this comment.
This is now a repeated request, so we'll now be expecting a vector of nack requests.
This is done so that instead of sending 1 nack option for a vector of offsets in a single Request, we can have a vector of requests where we'll have 1 nack option corresponding to 1 offset (a 1:1 mapping that we'll honor internally).
This is done this way so as to not break backward compatibility (for now).
You can go through the discussion over this decision here
| if request.request.HasField("nack_options") | ||
| else None | ||
| ) | ||
| await self.__source_nack_handler(NackRequest(offsets=offsets, nack_options=opts)) |
There was a problem hiding this comment.
Due to the proto changes suggested above, we'll need to handle this differently. You can reference the implementation in other SDKs.
Simplest clear reference for this would be the rust SDK implementation here
2 participants
Closes #348