Skip to content
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

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

ninaagrawal
Copy link

added some documentation for developers

@ninaagrawal ninaagrawal force-pushed the ninaagrawal/developer_docs branch from 101f31b to 7427359 Compare October 30, 2024 14:30
fix: allow flowchart to be recognized by site
@ninaagrawal ninaagrawal force-pushed the ninaagrawal/developer_docs branch from 7427359 to 2b575be Compare October 30, 2024 15:42
@j-lanson
Copy link
Collaborator

I'm looking for something a little lower-level, along the lines of this quick sketch:

developer_docs_graphic

The goal is that a developer can read it to understand quickly how control flows through the different components of the hipcheck core and SDK around querying

@j-lanson j-lanson self-requested a review October 30, 2024 17:08
@j-lanson j-lanson added the type: chore Clean up or management task. label Oct 30, 2024
Copy link
Collaborator

@j-lanson j-lanson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See comment

@alilleybrinker alilleybrinker changed the title Ninaagrawal/developer docs Improved developer documentation with flowcharts Nov 6, 2024
…/hipcheck into ninaagrawal/developer_docs

fix: needed updated changes from branch
Comment on lines +15 to +17
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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

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.

Copy link
Collaborator

@j-lanson j-lanson left a 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(), as AwaitingResult?
  • messages from HC core arrive at a plugin at plugin_engine.rs::HcSessionSocet::listen(), how do they get to PluginEngine::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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: chore Clean up or management task.
Projects
Status: In Progress
Status: No status
Development

Successfully merging this pull request may close these issues.

2 participants