-
Notifications
You must be signed in to change notification settings - Fork 25
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
Implement the new trigger and generic task node structure #35
Conversation
05ea0ba
to
8ce3e99
Compare
04c8478
to
460df3c
Compare
New dependencies detected. Learn more about Socket for GitHub ↗︎
|
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.
Added my comments to the current design.
protobuf/avs.proto
Outdated
} | ||
|
||
message TaskNode { | ||
TaskType node_type = 1; |
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.
Match the variable name node_type
with the type name TaskType
. In my opinion we can simplify the names with the followings:
message TaskNode
-> message Node
TaskType
-> NodeType
, and make it NodeType type = 1
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.
Match the variable name node_type with the type name TaskType
Yes, will change to task_type
In my opinion we can simplify the names with the followings:
message TaskNode -> message Node
TaskType -> NodeType, and make it NodeType type = 1
I actually name it on purpose
- Node is too generic in our field. We have node in list, we have node in server. It's like calling something
Item
. Because of that, I want to avoid any confusion down the line, and explicitly calling it TaskNode. it's also more grep-able if we have to search code. type
I want to avoid the case when we access it like thissomething.type
just want to avoid someone accidently think this maybe the type of the object/class. And also same with searchable..node_type
let me know if you still think in redundant, i can change.
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.
okay, naming them compresive works. It’s just a naming convension.
Also, I was asking about TaskType node_type = 1;
, that maybe we should calle it TaskType task_type = 1;
for consistency?
protobuf/avs.proto
Outdated
string name = 3; | ||
|
||
// based on node_type one and only one of these field are set | ||
oneof task_body { |
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 TaskType already defines these categories, and the task_body values seem redundant, but let me get a screenshot from the Studio for furthur clarification.
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.
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 TaskType already defines these categories, and the task_body values seem redundant,
task_body is relevant to protobuf so it can decode the object becasue we're using oneof here
This is one-off https://protobuf.dev/programming-guides/proto3/#oneof
oneof take the value of field name by default so I was trying to be more user fiendly and having the extra node_type.
Let me just merge them into one so it won't have this dup.
model/task.go
Outdated
Task: &avsproto.Task{ | ||
Id: &avsproto.UUID{ | ||
Bytes: taskID, | ||
}, |
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.
Isn’t id just a ulid string? I think we should just have id: string
instead of return a nested structure id: { bytes: '01JCKCRTZBS158BRP8E42P2DQW' }
. This nested format doesn’t provide any real benefit to the user and only complicates retrieving the string representation of the ID.
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.
Besides, I am using the ulid on the frontend, and find the upper cases are a little hard to read, should we return the id in lower case?
Comparison:
uppercases:
{ id: '01JCM1TGR85E59ZYEG5Q7WHKZ6' }
lowercases:
{ id: '01jcm1tgr85e59zyeg5q7whkz6' }
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.
Isn’t id just a ulid string? I think we should just have id: string
uuid/ulid is actually a byte array. string is a way to re-present it in human readable form, aka canonical form.
I used []byte
before (thus the name) but it's not easy to enter []byte
in the gRPC UI thus I resorted to using string so ppl can type it out
Let me update to direct string instead.
Besides, I am using the ulid on the frontend, and find the upper cases are a little hard to read, should we return the id in lower case?
You can display uppercase/lowecase on the front-end. doesn't matter. the alphabet doesn't have lowecase. server side will convert it eventually.
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.
okay, let’s keep the upper case for the id, so we don’t care about conversion on the server side.
yeah, bytes have to be converted to string for transmission, so I think we should remove the bytes property key, to achieve { id: '01JCM1TGR85E59ZYEG5Q7WHKZ6' }
protobuf/avs.proto
Outdated
|
||
// repeatable means a task can continue to run even after the first execution. | ||
// By default, recurring is false, task will only executed once. | ||
bool recurring = 10; |
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 it’s a boolean varialbe, I suggest that we name it is_recurring
, instead of recurring
. At least in javascript that norm is with a prefix is
.
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.
will change
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.
okay, we have made a decison about this last year. Checking out the automation hub, I think the below set up makes more sense.
maxExeCount: number
0 - good till cancel, equals to is_recurring
1, 2, 3, .... - the actual execution count
The reason being that with is_recurring: bool
we couldn’t limit the number of execution needed for a reccuring job.
Formatted console.log output of example.js
@chrisli30 Ready to review |
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.
Cood looks good. I like the encapsulation of Conditions in the examples/static_codegen/avs_pb.js
Implement change to our task trigger/node https://docs.google.com/document/d/1DM0VJ0hUnC4FIWAbNSKAaLfQ3U7EI3GRd0DcQvUA8B8/edit?pli=1&tab=t.0#heading=h.oi6mw4tp84nj
This PR mainly handles 2 things:
edges
field to maintain relationship between nodesnext
fromnodes
. Edges handles it now.Will update https://github.com/AvaProtocol/ava-sdk-js/pulls next to conform to the new protobuf and add new method.
An example task.
another example with fixed schedule
another one with cron: