mirror of
https://github.com/MichaelMure/git-bug.git
synced 2024-12-14 08:45:30 +03:00
7348fb9edb
I believe the issue was twofold: When done importing, the calling context is likely still valid, so if the output channel is not read enough and reach capacity, some event producer down the line can be blocked trying to send in that channel. When closing it, this send is still trying to proceed, which is illegal in go. In rateLimitHandlerClient, there was a need to 2 different type of output channel: core.ExportResult and ImportEvent. To do so, the previous code was using a single channel type RateLimitingEvent and a series of goroutines to read/cast/send to the final channel. This could result in more async goroutine being stuck trying to send in an at-capacity channel. Instead, the code now use a simple synchronous callback to directly push to the final output channel. No concurrency needed anymore and the code is simpler. Any of those fixes could have resolved the data race, but both fixes is more correct.
41 lines
605 B
Go
41 lines
605 B
Go
package github
|
|
|
|
import "github.com/shurcooL/githubv4"
|
|
|
|
type ImportEvent interface {
|
|
isImportEvent()
|
|
}
|
|
|
|
type RateLimitingEvent struct {
|
|
msg string
|
|
}
|
|
|
|
func (RateLimitingEvent) isImportEvent() {}
|
|
|
|
type IssueEvent struct {
|
|
issue
|
|
}
|
|
|
|
func (IssueEvent) isImportEvent() {}
|
|
|
|
type IssueEditEvent struct {
|
|
issueId githubv4.ID
|
|
userContentEdit
|
|
}
|
|
|
|
func (IssueEditEvent) isImportEvent() {}
|
|
|
|
type TimelineEvent struct {
|
|
issueId githubv4.ID
|
|
timelineItem
|
|
}
|
|
|
|
func (TimelineEvent) isImportEvent() {}
|
|
|
|
type CommentEditEvent struct {
|
|
commentId githubv4.ID
|
|
userContentEdit
|
|
}
|
|
|
|
func (CommentEditEvent) isImportEvent() {}
|