-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
allow promises to fail #2257
allow promises to fail #2257
Conversation
@noffle could I get you to take a look at this one? |
@@ -184,6 +184,9 @@ func (ds *dagService) GetNodes(ctx context.Context, keys []key.Key) []NodeGetter | |||
select { | |||
case blk, ok := <-blkchan: | |||
if !ok { | |||
for _, p := range promises { | |||
p.Fail(ErrNotFound) | |||
} |
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 fails all NodeGetter
s, right? Why can't we just let the failing ones fail and return the ones that do arrive?
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.
anything that does arrive will arrive by the time we get here
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.
Oh, I see! !ok
is true when the channel has been closed. Yes, that makes good sense. :)
I think I see a nasty edge case here though: consider the scenario where some NodeGetters have their Node successfully sent to their recv
channel, but nobody has called Get()
on them yet. The above code executes, sending down ErrNotFound
to the err
channel of all NodeGetters -- even the ones that previously succeeded. So now you have some NodeGetters with data in both the recv
channel and the err
channel. However, select
chooses at random when there are multiple case
s that can run. This means there's a chance that calling Get()
on a good NodeGetter will yield an error.
This is a long winded say of saying "we should probably only fail the NodeGetters that actually failed rather than all of them".
ff3373a
to
46152f2
Compare
46152f2
to
4d0a37a
Compare
817af36
to
11eba04
Compare
License: MIT Signed-off-by: Jeromy <jeromyj@gmail.com>
License: MIT Signed-off-by: Jeromy <jeromyj@gmail.com>
11eba04
to
b5a78b1
Compare
License: MIT Signed-off-by: Jeromy <why@ipfs.io>
b5a78b1
to
5a0b6e5
Compare
This allows the nodepromise thing to fail. In cases such as
ipfs refs -r
run offline when not all blocks are local, ipfs currently hangs.License: MIT
Signed-off-by: Jeromy jeromyj@gmail.com