-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
hybrik: fix bug with improper connections #211
hybrik: fix bug with improper connections #211
Conversation
This is a small patch to address a bug that was causing incorrect connections to be constructed. Connections were generated referencing non-existent elements and some elements were left unconnected.
Codecov Report
@@ Coverage Diff @@
## master #211 +/- ##
=======================================
Coverage 78.62% 78.62%
=======================================
Files 29 29
Lines 2914 2914
=======================================
Hits 2291 2291
Misses 372 372
Partials 251 251 Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @zsiec, thank you very much for contributing! :D Overall looks good, but maybe we can avoid some repetition.
I had forgotten that we never added tests to the hybrik provider. Perhaps we can take a look at doing that next? x)
provider/hybrik/hybrik.go
Outdated
activeRunning = "running" | ||
activeWaiting = "waiting" | ||
hls = "hls" | ||
transcodeElementIDTempate = "transcode_task_%s" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo:
transcodeElementIDTempate = "transcode_task_%s" | |
transcodeElementIDTemplate = "transcode_task_%s" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 thanks for catching
transcodeSuccessConnections[i] = hwrapper.ToSuccess{Element: "transcode_task" + strconv.Itoa(i)} | ||
transcodeSuccessConnections := make([]hwrapper.ToSuccess, len(transcodeElementIds)) | ||
for i, id := range transcodeElementIds { | ||
transcodeSuccessConnections[i] = hwrapper.ToSuccess{Element: id} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we range through elements and add element.UID to the transcodeSuccessConnections slice? Something like:
for i, e := range elements {
transcodeSuccessConnections[i] = hwrapper.ToSuccess{Element: e.UID}
}
Then we don't need an additional slice, I think. And that would also keep the logic to generate the element id inside the monutTranscodeElement function.
If we do that, can you also make the constant transcodeElementIDTemplate
local to that function?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change was made because elements
holds a slice of all elements and in this case, not only the transcode task elements, but at least one source element created and appended before we run the logic to create the transcode task elements. (this was causing incorrect connections to be generated)
Rather than assume we have a single source element and doing a range over elements[1:]
(along with assuming there are no elements between the source and the transcode tasks), I thought it would be less error prone to explicitly track transcode tasks. This allows us to freely add elements before the transcode elements without having to change that slice offset.
We can safely change
transcodeElementIds = append(transcodeElementIds, fmt.Sprintf(transcodeElementIDTemplate, taskIndex))
to
transcodeElementIds = append(transcodeElementIds, e.UID)
but we make use of transcodeElementIDTemplate
again in presetsToTranscodeJob
when generating connections to packagings tasks (line 293) (perhaps we could send the transcodeElementIDTemplate
into mountTranscodeElement
to keep it out of the global scope?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for clarifying! This makes sense, my bad x)
We can keep the code as is :D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cheers! I was tripped up by the code a few times myself, I think we can clean it up a little :)
addressing CR comments
@fsouza thanks for the review! This was a simple patch to get things working again, We will likely take a pass at rewriting it completely, similar to what we did for the new Bitmovin provider in #210. (although abstractions will diverge slightly as the Hybrik and Bitmovin APIs differ) We want to simplify the functions and reduce the amount of state that shares scope, and of course, add tests :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀
This is a small patch to address a bug that was causing incorrect connections to be constructed. Connections were generated referencing non-existent elements and some elements were left unconnected.