-
Notifications
You must be signed in to change notification settings - Fork 166
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
Bridge: add /events
poller
#1363
Conversation
681bbf1
to
ba93978
Compare
ba93978
to
dd40495
Compare
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.
Nothing looks wrong, left some cleanup notes though (can be addressed in another PR).
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.
I'll take a look at making the itertools change while waiting on the rest of this stuff to coalesce. 🙏🏻
OSS Review: itertoolsThis popular extension crate adds new methods for iterators. The selected version is not the newest, but it aligns with a selected |
c80d904
to
4bca290
Compare
4bca290
to
6f4f67c
Compare
I'd call this "quick and dirty" but it was actually a bit of a hefty lift to pull together. It is however fairly dirty. The want is to be able to pull messages from `/events` and feed them into a receiver output. The flow we'd see with `SenderInput` paired with `ReceiverOutput` is what we want, but the existing typing didn't allow for this. Refactors were needed to: - lift out the parts from the HTTP server that run payloads through transformations then forward to an output. - update config to account for a new type of receiver: a "poller". - new traits/types for the poller to differentiate it from the standard webhook receiver (to ensure we don't accidentally pass one through and try to bind it to a URL). - Lots of "connective tissue" in the form of converters between config values and concrete ones that can actually do things. Some of the "connective tissue" exists purely to mimic bits and pieces that existed for either the other receivers or senders (remember, this case is odd in that it's similar to both). Refactorings aside, the poller itself boasts an exponential backoff for both error cases (either from `/events` or from the output) as well as for the case where the `/events` iterator is "done." This diff comes with a promise that we will (soon) give these additions another look at clean up the stuff that doesn't make sense or feels redundant.
Co-authored-by: Jonas Platte <158304798+svix-jplatte@users.noreply.github.com>
OSS Review: itertools This popular extension crate adds new methods for iterators. Useful in this case as it cleans up a previous call to `fold()` designed to partition a collection into 2 collections that can't be expressed cleanly with a plain `partition()`. The selected version is not the newest, but it aligns with a selected version already included in the project transitively.
There's a new authtoken endpoint for creating fresh events subscriptions. In the response is a base64 encoded json structure including the authtoken to use, the subscription id, and the app id - everything we need to build an appropriate URL for fetching events from the stream.
82a1413
to
feb4657
Compare
This gives access to the needed beta `events_subscription` API.
There were some gaps in the initial implementation. This switches to setting a flag within the message handling loop and breaking the loop so that the sleep time penalty (or reset) can be assessed at the bottom of the loop more consistently. Mostly this is about making sure any single message that has a problem makes the whole iterator batch retry.
feb4657
to
5536e9a
Compare
Some relatively new stuff since last review added, starting with 47e35a7
|
Looks like the `done` field doesn't signify we're at the end of the topic like I originally thought. Using the count as a proxy for this works well enough for now, but may not in the future if we expose filters like channels/event types. Follow-on from #1363
Looks like the `done` field doesn't signify we're at the end of the topic like I originally thought. Using the count as a proxy for this works well enough for now, but may not in the future if we expose filters like channels/event types. Follow-on from #1363
We've got 3 places where we log errors in the poller loop and this one somehow wound up logging as `trace!` instead of `error!` like the rest. Follow-on from #1363
## What's Changed * Bridge: add `/events` poller by @svix-onelson in #1363 * server: Optimize all external host dependencies for faster rebuilds by @svix-jplatte in #1365 * Bridge: log svix client errors as error, not trace by @svix-onelson in #1368 * Bump Cargo lockfiles by @svix-jplatte in #1370 * server: add configuration to for changing service name on OpenTelemetry by @LeoZ100 in #1371 * build(deps): bump openssl from 0.10.64 to 0.10.66 in /bridge by @dependabot in #1372 * bridge: Require type field for kafka input, output by @svix-jplatte in #1374 * Bump OpenAPI spec and regenerate libs by @svix-lucho in #1375 ## New Contributors * @LeoZ100 made their first contribution in #1371 **Full Changelog**: v1.25.0...v1.26.0
Helps with https://github.com/svix/monorepo-private/issues/8654
Depends on client lib updates (not yet available).
I'd call this "quick and dirty" but it was actually a bit of a hefty lift to pull together. It is however fairly dirty.
The want is to be able to pull messages from
/events
and feed them into a receiver output.The flow we'd see with
SenderInput
paired withReceiverOutput
is what we want, but the existing typing didn't allow for this.Refactors were needed to:
Some of the "connective tissue" exists purely to mimic bits and pieces that existed for either the other receivers or senders (remember, this case is odd in that it's similar to both).
Refactorings aside, the poller itself boasts an exponential backoff for both error cases (either from
/events
or from the output) as well as for the case where the/events
iterator is "done."This diff comes with a promise that we will (soon) give these additions another look at clean up the stuff that doesn't make sense or feels redundant.