SendContext fix

[pashaosipyants]

SendContext didn't check if context is done first. Instead, in case ctx is done and channel to send has a free buffer, it chose randomly either to return false or send value to the channel.

Added a test that failed randomly on previous version of SendContext.

Changes to be committed:
modified: item.go
modified: item_test.go

[teivah]

Thanks for your PR @pashaosipyants, you're perfectly right. One minor thing to make the comment slightly more meaningful imo.

[maguro]

Why does the context done channel need to have the highest priority? Just curious.

[teivah]

Why does the context done channel need to have the highest priority? Just curious.

@maguro No hard constraint about it. Yet, semantically I think this might be closer to what users expect from such a function.

[maguro]

Why does the context done channel need to have the highest priority? Just curious.

@maguro No hard constraint about it. Yet, semantically I think this might be closer to what users expect from such a function.

mstm. I was just making sure it wasn't required for a properly functioning RxGo framework. The reason I asked is that I ran into a nasty RxGo bug that's near impossible to reproduce. The gist of it seems to be that the context gets canceled but there are RxGo routines that are stuck trying to send items, or something like that. It's super hard to reproduce.

It may make sense to take a look at all the places that context participates in selects in RxGo.

[teivah]

The gist of it seems to be that the context gets canceled but there are RxGo routines that are stuck trying to send items, or something like that. It's super hard to reproduce.

@maguro Mmh, interesting. Perhaps, we could try implementing some form of "fuzz testing" where contexts could be randomly canceled throughout various workflows where contexts are involved?

[maguro]

The gist of it seems to be that the context gets canceled but there are RxGo routines that are stuck trying to send items, or something like that. It's super hard to reproduce.

@maguro Mmh, interesting. Perhaps, we could try implementing some form of "fuzz testing" where contexts could be randomly canceled throughout various workflows where contexts are involved?

I'm not sure how useful that would be in that one could never be really sure that certain states were being tested. I've been giving this a bit of thought given the problems I've encountered in the other PR, #289. For this kind of framework, it's hard to inject testing points "after the fact".

If I were to write this from scratch, I think I would think of things as assemblies of stateful components that exchange events. Unit testing these stateful components would be straightforward. It would then be possible to inject testing shims and mocks to test collaborations. Such a setup would facilitate the comprehensive testing that is needed and where simple code coverage reports would give a false sense of security.