-
Notifications
You must be signed in to change notification settings - Fork 92
feat: watch account using websocket and handlings #304
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
base: master
Are you sure you want to change the base?
Conversation
🦋 Changeset detectedLatest commit: 51fb06b The changes in this PR will be included in the next version bump. This PR includes changesets to release 6 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
|
||
| const closedRef = { value: false }; | ||
|
|
||
| let pollTimer: NodeJS.Timeout | null = null; |
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.
note: this type can't be used since it should be runtime agnostic
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.
yes, would need to find better way to type it. functionally it works
| }; | ||
|
|
||
| // Main loop: attempts WS connection with retry; falls back to polling after max retries. | ||
| const run = async () => { |
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.
thought: this is a complex function. how can we reduce complexity and improve performance?
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 did move out the function into its own selve but the parameters became quite complex, might be able to extract out the stream parsing functionality, will need to investigate more
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.
question: is this heartbeat, retry, etc running on the connection or method level?
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.
these should be on application / method and not on the connection / underlying protocol. As these are for handlings of fallback which would be from websocket protocol to http
|
@tobeycodes also mentioning this example repo where I sketch up things
|
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.
Is this ready for review? It's in draft status
1d7a528 to
51fb06b
Compare
Sorry, forgot to mark as ready for review. Also, added some cleanups and rebase to latest |
Problem
Websocket subscriptions connection can fail and having fallback using http/rpc would improve the usage and reliability of handling data subscriptions/fetching.
Summary of Changes
Part of efforts in introducing watchers for gill. This PR is introduce a unified watcher which can be consumed by specific watcher e.g watch account and watch program logs.
In this PR two main functions are introduced:
unified-watcherwhich can be used to create a watcher with flexible handlings for what is being watchedwatch-accountwhich watch address through websocket with rpc/http fallback usingunified-watcheras baseexample usage
script
watch-account-node.tsrunning the script
Potential improvements left out from this PR
Fixes #281 (partial)