Unpause, Pause, and Cancel methods should return an error channel (with max 1 value sent) rather than an error
- Dominant language
- Go
- Stars
- 103
- Forks
- 41
- PR merge metrics
- No merged PRs in 30d
Description
# What
Convert the following methods on the GraphsyncExchange interface:
```golang
type GraphsyncExchange interface {
//...
// UnpauseRequest unpauses a request that was paused in a block hook based request ID
// Can also send extensions with unpause
UnpauseRequest(RequestID, ...ExtensionData) error
// PauseRequest pauses an in progress request (may take 1 or more blocks to process)
PauseRequest(RequestID) error
// UnpauseResponse unpauses a response that was paused in a block hook based on peer ID and request ID
// Can also send extensions with unpause
UnpauseResponse(peer.ID, RequestID, ...ExtensionData) error
// PauseResponse pauses an in progress response (may take 1 or more blocks to process)
PauseResponse(peer.ID, RequestID) error
// CancelResponse cancels an in progress response
CancelResponse(peer.ID, RequestID) error
// CancelRequest cancels an in progress request
CancelRequest(context.Context, RequestID) error
//...
}
```
to
```golang
type GraphsyncExchange interface {
//...
// UnpauseRequest unpauses a request that was paused in a block hook based request ID
// Can also send extensions with unpause
UnpauseRequest(RequestID, ...ExtensionData) <-chan error
// PauseRequest pauses an in progress request (may take 1 or more blocks to process)
PauseRequest(RequestID) <-chan error
// UnpauseResponse unpauses a response that was paused in a block hook based on peer ID and request ID
// Can also send extensions with unpause
UnpauseResponse(peer.ID, RequestID, ...ExtensionData) <-chan error
// PauseResponse pauses an in progress response (may take 1 or more blocks to process)
PauseResponse(peer.ID, RequestID) <-chan error
// CancelResponse cancels an in progress response
CancelResponse(peer.ID, RequestID) <-chan error
// CancelRequest cancels an in progress request
CancelRequest(context.Context, RequestID) <-chan error
//...
}
```
# Why
The above methods delegate to the RequestManager and ResponseManager, and if you look at the code for their implementation, they all perform a channel wait implicitly. This makes them significantly more blocking than they need to be, and perhaps we want to let calling code decide when to wait for the results.
In particular we may want to unlock mutexs between the call and the wait.
Flagging as needs discussion as its a breaking change
Contributor guide
Assessment
This issue has not been assessed yet.