Investigate/suppress errors in #reflector-logs #25
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/reflector.go#25
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "%!s()"
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?
#reflector-logs is full of errors like below. If we know they aren't causing any issues (I know we thought they might be at one point), we should suppress them.
@jackrobison still waiting for details from you
assign it back to me after
@lyoshenka this seemed to be caused by something not being handled correctly when a connection is closed abruptly (while bytes are being written). It seems to be initiated during a download of a stream by the client downloading from reflector plus another fast peer, where the peer the blob downloads from oscillates between the two (and thus has a lot of cancellations mid-transfer). Another condition that may be required is where the stream is only partially uploaded to reflector (and had a similar mid-blob-upload cancellation)
A possible issue reproducing locally is that the local reflector.go blob server will reply (at least for me) with frames up to 262144 bytes long vs < 20000 bytes for the real one.
The correct answer seems to be to just ignore these. They happen when the other side closes the connection without letting us know (because it has no way to let us know). Fixed in
7a618f4
.