feat: Provider::subscribe_logs
#339
Conversation
klkvr
requested review from
DaniPopes,
gakonst,
mattsse,
onbjerg and
prestwich
as code owners
There was a problem hiding this comment.
@DaniPopes can we somehow unify the usage of Subscription<T> and PollChannel<T> to have a single front-end that works for both polling and pubsub?
using channels should allow us to erase the type of the backing stream/coroutine
|
@prestwich I think so, but I feel that would complicate things quite a bit for not much benefit? |
|
it means that users would follow the same API regardless of provider and get automatically upgraded to pubsub subscriptions when they change endpoints (unless they specifically want to downgrade to polling for some reason) |
|
i agree w prestwich here, this would most likely also give us transport stacking back? although i'd leave that for a follow up since it's somewhat unrelated to this pr |
| Self { sub, _phantom: PhantomData } | ||
| } | ||
|
|
||
| /// Converts the subscription into a stream. |
There was a problem hiding this comment.
This results in an unnameable type. Is there any situation in which a user would want to name the resulting stream?
There was a problem hiding this comment.
I guess we want a similar thing as SubscriptionStream here with the type we decode on poll_next?
There was a problem hiding this comment.
ideally we have these all work the same way. can convert this to issue?
|
Regardless, that's not in scope for this PR. Opened #346 to capture. |
|
re-running CI before merge |
Motivation
Adds
Provider::subscribe_logsandEvent::subscribemethodsSolution
PR Checklist