Better tracking (Size and failure reason) #35
No reviewers
Labels
No labels
area: devops
area: discovery
area: docs
area: livestream
area: proposal
consider soon
dependencies
Epic
good first issue
hacktoberfest
help wanted
icebox
level: 1
level: 2
level: 3
level: 4
needs: exploration
needs: grooming
needs: priority
needs: repro
needs: tech design
on hold
priority: blocker
priority: high
priority: low
priority: medium
resilience
Tom's Wishlist
type: bug
type: discussion
type: improvement
type: new feature
type: refactor
type: task
type: testing
unplanned
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: LBRYCommunity/lbry.go#35
Loading…
Reference in a new issue
No description provided.
Delete branch "better-tracking"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
WiP
This PR can only be reviewed/merged after #25 and #34 are merged
also it depends on https://github.com/lbryio/internal-apis/pull/522
passing around the mutex to all these functions is a bad pattern. if the mutex is protecting something, you should create a new struct and put the mutex and the thing into it. then you just pass the struct around, and the two are always together.
@ -40,19 +44,19 @@ func NewUCBVideo(id, title, channel, description, publishedAt, dir string) ucbVi
}
}
why are these fields here if they never get used?
and having syncedVideosMux on each video is weird. whats going on?
@ -373,3 +443,3 @@
s.grp.Add(1)
go func() {
go func(i int) {
defer s.grp.Done()
why does this function return a pointer to an error?
@ -373,3 +443,3 @@
s.grp.Add(1)
go func() {
go func(i int) {
defer s.grp.Done()
because the function is run as a deferred and needs to read/write to the error being returned by the original function. Is this a bad pattern?
@ -40,19 +44,19 @@ func NewUCBVideo(id, title, channel, description, publishedAt, dir string) ucbVi
}
}
there is only one mutex for the whole map, the pattern is the same you used locally in the function where a name is generated for the claim.
I however agree with your comment about passing down the mutex, I'm going to correct that.
@ -373,3 +443,3 @@
s.grp.Add(1)
go func() {
go func(i int) {
defer s.grp.Done()
well actually to be correct it's not returning a pointer to an error, it's accepting a pointer to an error so that I can change it from within.