Use Recordbatch with TaskResult #10188
Merged
Conversation
This file contains 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
Adding an additional inverse map allows us to reuse that map on multiple places, where we need to ValueType for a corresponding class.
The RecordBatch is filled with the TaskResultBuilder and returned with the TaskResult. The RecordBatch is written to the Dispatcher in the ProcessingScheduleService.
This allows to further reduce the dependency from the LogStreamWriters
This was referenced Aug 25, 2022
deepthidevaki
approved these changes
Aug 26, 2022
|
bors r+ |
|
Build succeeded: |
zeebe-bors-camunda bot
added a commit
that referenced
this pull request
Aug 26, 2022
10191: Handle append error differently based on ResultBuilder r=Zelldon a=Zelldon ## Description :x: Blocked by #10188 This PR adds Either to the RecordBatch as return value. This allows to handle the error case differently. For example in the Processing right now we want to throw an exception, but later this can also handled differently which is why we added here a separate Method on the ProcessingResultBuilder. This is discussable whether we already want that. What we need and want is to being able to handle failed appends in the consumers of the ProcessingScheduleService. Means at the TaskResultBuilder we want to now whether it was successful or not and just stop to append more records. This is slightly similar to how we did it before. This fixes a critical bug #10147 <!-- Please explain the changes you made here. --> ## Related issues <!-- Which issues are closed by this PR or are related --> closes #10147 related #10001 Co-authored-by: Christopher Zell <zelldon91@googlemail.com>
zeebe-bors-camunda bot
added a commit
that referenced
this pull request
Aug 26, 2022
10196: Introduce ProcessingResponse r=Zelldon a=Zelldon ## Description blocked by #10191 ✅ blocked by #10188 ✅ Introduce the ProcessingResponse, which encapsulates the information of the Record which should be send as response on a user command and the request- and streamId which identifies the request. The ProcessingResponse usage replaces the usage of the CommandResponseWriter, and deletes several now unused code. <!-- Please explain the changes you made here. --> ## Related issues <!-- Which issues are closed by this PR or are related --> closes #10001 Co-authored-by: Christopher Zell <zelldon91@googlemail.com>
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.
Description
Prework was to create an inverse static EventRegistry -> TypeRegistry to reuse this in the different result builders. This allows getting the value type for a certain record class.
The RecordBatch is now part of the TaskResult. The RecordBatch is filled with the TaskResultBuilder and returned with
the TaskResult. The RecordBatch is written to the Dispatcher in the ProcessingScheduleService.
After migrating to the RecordBatch we were able to delete
writeRecordsToStream, which further reduce the dependencies. For example Backup module no longer depends on logstream.Next step: Migrate the response writing to record batch, this allows to remove further dependencies.
Related issues
related #10001
Definition of Done
Not all items need to be done depending on the issue and the pull request.
Code changes:
backport stable/1.3) to the PR, in case that fails you need to create backports manually.Testing:
Documentation:
Please refer to our review guidelines.