-
Notifications
You must be signed in to change notification settings - Fork 6
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
Improved developer documentation with flowcharts #546
base: main
Are you sure you want to change the base?
Conversation
101f31b
to
7427359
Compare
fix: allow flowchart to be recognized by site
7427359
to
2b575be
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.
See comment
feat: added picture of the flowchart
…/hipcheck into ninaagrawal/developer_docs fix: needed updated changes from branch
direction TB | ||
hipcheck_proto --Opens an rpc protocol so Hipcheck can request queries to the plugin and the plugins may issue queries to other plugins-->finishHipcheck | ||
end |
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.
Not relevant to this particular graph, we're discussing what happens once the gRPC channel is already open. Also, if this were in the graph it would happen before the start
block.
recv--creates a variable called msg_chunks that will get the result from recv_raw.-->recv_raw --returns a queue of messages returned from send function if the grpc channel is still open as a vector -->recv --reads the messages from recv_raw --> finishSDK | ||
end | ||
|
||
Z-- The send function sends a grpc query from the plugin to the hipcheck server. The query parameter is given the RPC type InitiateQueryProtocolResponse-->ZA --Control transfers back to SDK-->ZB |
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.
The specific type InitiateQueryProtocolResponse
is not necessary here
subgraph Z["SDK"] | ||
direction TB | ||
start--query's() parameters are the input value and target plugin/query endpoint from the starting plugin's query trait's run() function.--> | ||
query --The target plugin/query endpoint is converted from the generic T to a QueryTarget. The input is converted to a JSON value with an InvalidJSONInQuery Key error if not properly converted. The variables are named query_target and input. From there query's inner function, query_inner() is called with the query_target and input as parameters--> query_inner-- During normal execution, when the engine is not a mock engine, the query() function creates a QueryTarget object and calls the send() function. The Query object is the send() function's parameter.-->send |
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 don't need to describe the error paths, particularly to do with JSON deserialization.
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 would like this graph to answer these outstanding questions:
- once gRPC messages are received by HC core, how do they make it up to
engine.rs::query()
, asAwaitingResult
? - messages from HC core arrive at a plugin at
plugin_engine.rs::HcSessionSocet::listen()
, how do they get toPluginEngine::recv_raw()
Also, please remove the erroneously added .jpg
files, they should not be part of the PR.
Signed-off-by: Nina "Nino" Agrawal <[email protected]>
added some documentation for developers