-
Notifications
You must be signed in to change notification settings - Fork 63
Throw better errors on the RESULT and FUNCTION_RESULT methods #568
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
Conversation
packages/rpc/src/endpoint.ts
Outdated
} catch (error) { | ||
const {message} = error as Error; | ||
throw new Error( | ||
`Error in function result listener. Method: ${method} Error: ${message}`, |
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 believe the second parameter in this case is a function ID, which will just be a random identifier. I don’t think this will be useful for you in debugging, although I guess there is no harm in providing it.
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, you are right that they are not the method. It looks like we only get the callId, the error if present and any other args. I'm not sure if this is going to help us debugging the issue that we have. Do you have any other ideas to get more relevant data here?
interface MessageMap {
...
[RESULT]: [string, Error?, any?];
...
[FUNCTION_RESULT]: [string, Error?, any?];
}
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.
Looks great, thanks for this @josemiguel-alvarez! Thanks also for fixing the old github actions, I will fix anything else that comes up while trying to release the new version with this fix.
What
This PR improves error handling in the RPC endpoint by adding more contextual information when errors occur in the RESULT and FUNCTION_RESULT methods.
Why
When errors occurred in result listeners, the original error messages lacked context about which method was being called, making debugging difficult. This change adds the method name to the error message, providing clearer information about where the failure occurred.