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

add sankey chart action server to client protos #21

Merged
merged 21 commits into from
Oct 8, 2024

Conversation

Augustyniak
Copy link
Contributor

@Augustyniak Augustyniak commented Oct 3, 2024

Fixes BIT-3836

@Augustyniak Augustyniak marked this pull request as ready for review October 3, 2024 16:53

// A state step provides the configuration used to name Sankey chart states. Each state step corresponds
// to a single transition between two states in the workflow.
message NodeStep {
Copy link
Contributor

Choose a reason for hiding this comment

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

For associating with the transition I had thought we could just embed it directly on the Transition proto / LogMatcher proto, that way we avoid having to duplicate all the state transitions and it ought to make it easier to construct the necessary bits on the workflow engine

That said I haven't spent time looking at the client code so lmk if you think this format works better

Copy link
Contributor Author

Choose a reason for hiding this comment

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

from the perspective of the client It would me simpler to have this be a property on the LogMatcher. I wanted to avoid this though not to tie the implementation of the LogMatcher to any specific action but let me rework this.

// to a single transition from a workflow origin state to a workflow target state.
message Node {
// The ID of the origin state.
string origin_workflow_state_id = 1 [(validate.rules).string = {min_len: 1}];
Copy link
Contributor

Choose a reason for hiding this comment

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

would this be the generated client ID? Or the FE ID? Not sure how useful the generated ID would be since I it might vary between workflow constructions (I think)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is the ID that's generated server-side and yes, looking at the code it can change between workflow's constructions. We could probably change the logic so that the generate IDs stay the same between consecutive workflow constructions (I haven't verified that) but for now I will just remove the state_ids from here since they are not required for the absolute mvp

@Augustyniak Augustyniak requested a review from snowp October 8, 2024 18:01
@Augustyniak
Copy link
Contributor Author

@snowp should be ready for re-review

}

// Extracts the value from a field.
message FieldExtracted {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we have this duplicated in a few places, wonder if we should reuse? Not a blocker, just curious

Copy link
Contributor Author

Choose a reason for hiding this comment

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

made it shared

@Augustyniak Augustyniak merged commit a5caaf6 into main Oct 8, 2024
2 checks passed
@Augustyniak Augustyniak deleted the add-sankey-chart-action branch October 8, 2024 20:17
@github-actions github-actions bot locked and limited conversation to collaborators Oct 8, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants