-
Notifications
You must be signed in to change notification settings - Fork 7
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
Add ResponseListener.listenForResponseFromTransaction() #36
Conversation
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.
@bolekk, would you be so kind as to address Sonar's issues? They fall under critical "code smells." If you believe they are irrelevant, please let me know, and we will provide a corresponding resolution for those...
The PR is still in draft, I'll address everything once it's ready. |
7dbfc33
to
2880bdf
Compare
@chudilka1 I fixed most issues except two:
What should I do? |
It looks like this repo is missing a prettier <> eslint integration, which is how you make them play nicely together. |
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.
We should add a README entry for this method. Also, maybe we should probably update our README, docs & tutorials to make this the preferred method for listening for Functions responses given that listening based on requestId can break during reorgs.
src/ResponseListener.ts
Outdated
): Promise<FunctionsResponse> { | ||
return new Promise<FunctionsResponse>((resolve, reject) => { | ||
(async () => { | ||
let requestID: string = '' |
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.
nit: you shouldn't need to specify a type here. Typescript can infer the type based on the initial empty string value.
src/ResponseListener.ts
Outdated
return new Promise<FunctionsResponse>((resolve, reject) => { | ||
(async () => { | ||
let requestID: string = '' | ||
// eslint-disable-next-line |
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.
What is being disabled here? Usually eslint-disble statementments disable a single warning:
example: // eslint-disable-next-line no-implicit-any
(usually Copilot helps me do this automatically)
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.
Lint claims this can be const but it can't, right? (I'm using it before setting)
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.
Adding "@typescript-eslint/prefer-as-const" doesn't work
reject('Response not received within timeout period') | ||
}, timeout) | ||
|
||
const check = 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.
Might this method lead to a potential race condition if the check interval is much higher than the block time?
- User sends Functions request & calls
listenForReponseFromTransaction
which extracts the current requestId and listens for the response. - A reorg occurs and the reorged request is fulfilled before a
check
is called again. - Now we are listening for a response after the response has already occurred, meaning we won't ever actually hear it and this function hangs forever.
I think the logic is fine here as this only occurs with high checkInvervals, but maybe something to note in the README entry.
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. The old method has a similar problem - when we start listening after the response is emitted, we will miss it. It seems to be inherent to a functionsRouter.on() call. I'll add a note to README.
Thanks @justinkaseman! I'll take care of this now since I am the one who set up esLint to begin with. |
|
SonarQube Quality Gate |
Makes changes to code introduced in #36. Things to note: 1. 2 confirmations is a sensible default but have made 1 to reduce friction for devs so it works out of the box with local functions testnet. 2. Alternative could be to check inside `listenForResponseFromTransaction()` for ChainID 1337 (local funcs testnet) and then change the default confirmations to 1. 3. DevX Improvement: . README updates and added inline docs to the function so that it shows on however in the IDE
No description provided.