-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
[Functions] Heartbeat request support in Gateway handlers #11345
Conversation
bolekk
commented
Nov 20, 2023
•
edited
Loading
edited
- Functions Handler
- add a new method "heartbeat"
- add a configurable list of allowed heartbeat senders
- collect results from first F+1 nodes and send back in raw form
- Connector Handler
- asynchronously forward requests to Listener and cache results
- run a loop to collect OCR reports from Offchain Transmitter
- Listener
- add Timestamp field and validate it
I see that you haven't updated any README files. Would it make sense to do so? |
893696c
to
2ac4bfc
Compare
return | ||
} | ||
|
||
internalId := InternalId(fromAddr.Bytes(), request.RequestId) |
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.
If I get this right, the only purpose of this "internal ID" is to make it the key to map
.
However, you could simply make the key to be a value struct,
type heartbeatRequestKey struct {
sender []byte
requestId RequestID
}
and then this struct can be directly used by map which will does hashing internally.
This would look much clearer to me.
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 still need to have a single ID for request processing in the core node.
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.
Can't it be just RequestID?
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.
No because in the offchain scenario, RequestID is chosen by a user so we can't guarantee global uniqueness.
return | ||
} | ||
|
||
internalId := InternalId(fromAddr.Bytes(), request.RequestId) |
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 the idea that request.RequestId
will be generated in the same way that the contracts generate request ids?
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.
No, not at all. Request ID in the offchain heartbeat request is generated by the user. To guarantee global uniqueness, we need to combine it with user address.
2ac4bfc
to
25504df
Compare
1. Functions Handler - add a new method "heartbeat" - add a configurable list of allowed heartbeat senders - collect results from first F+1 nodes and send back in raw form 2. Connector Handler - asynchronously forward requests to Listener and cache results - run a loop to collect OCR reports from Offchain Transmitter 3. Listener - add Timestampi field and validate it
25504df
to
601579d
Compare
SonarQube Quality Gate |
1. Functions Handler - add a new method "heartbeat" - add a configurable list of allowed heartbeat senders - collect results from first F+1 nodes and send back in raw form 2. Connector Handler - asynchronously forward requests to Listener and cache results - run a loop to collect OCR reports from Offchain Transmitter 3. Listener - add Timestampi field and validate it