Skip to content
This repository has been archived by the owner on Feb 24, 2021. It is now read-only.

["Request"] Stream callback testing #239

Closed
pablisco opened this issue Jul 31, 2020 · 7 comments
Closed

["Request"] Stream callback testing #239

pablisco opened this issue Jul 31, 2020 · 7 comments

Comments

@pablisco
Copy link
Contributor

What would you like to see?

  • More negative tests for callback Streams.
  • A way to avoid sending events after calling end() on the stream

see: #199 (comment)

@nomisRev
Copy link
Member

nomisRev commented Aug 6, 2020

  • More negative tests for callback Streams.

Which behavior do you think isn't covered?

  • A way to avoid sending events after calling end() on the stream

What behaviour would you expect here? There is no way to avoid sending events after end.
I think we can only throw an exception in the producers scope, or send on to an async exception handler.

@pablisco
Copy link
Contributor Author

pablisco commented Aug 6, 2020

There is no way to avoid sending events after end.

Since I wrote this I've discovered CancelToken 😗👌

I guess that it may still be worth deciding what to do when we try to emit something and the stream is closed. It would be a bit of a breaking change, but my suggestion is to have emit fail with an exception and have the same set of functions called offer that are more lenient.

Either way, for the negative tests I was mostly talking about verifying (even if it's nothing) the behaviour of signalling after closure.

@nomisRev
Copy link
Member

nomisRev commented Aug 8, 2020

It would be a bit of a breaking change

Stream is not released yet, so that's not a concern yet. We should try to streamline all APIs before releasing them.

Sending an exception after closing is fine, that would make it our a first unsafe API tho :( For comparison in IO.async we ignore subsequent emissions instead of throwing an exception.

  • One option would be to expose the Queue API, which would be more in line with KotlinX's callbackFlow API. That, however, would push the responsibility of writing closing logic on the user.

  • Another option would be to expose :Boolean to the user which is now possible with Outstanding dequeues not completed on tryOffer1 #246.

@pablisco
Copy link
Contributor Author

I'm thinking, given that we have cancellable {} I'm wondering if we need to have callback {}. We could have CancelToken.unit to return a token that doesn't do anything keeping the API typesafe 🤔 i.e. what do we get extra from the callback API?

@nomisRev
Copy link
Member

Closed due to obsolete

@nomisRev
Copy link
Member

Closed due to obsolete

@nomisRev nomisRev reopened this Jan 13, 2021
@nomisRev
Copy link
Member

Closed due to obsolete

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants