Codecov Report

Attention: Patch coverage is 99.02913% with 1 line in your changes missing coverage. Please review.

📢 Thoughts on this report? Let us know!

Robot Results

@albinsuresh I don't think it makes sense to use @skip over skip. We previously used the @ prefix to denote special thin-edge.io property (e.g. in the registration syntax), however in the same payload we still use operation and payload...so the @skip does not look consistent (imho).

I'd be happy to hear other opinions on this. @didier-wenzek @jarhodes314

@albinsuresh I don't think it makes sense to use @skip over skip. We previously used the @ prefix to denote special thin-edge.io property (e.g. in the registration syntax), however in the same payload we still use operation and payload...so the @skip does not look consistent (imho).

I'd be happy to hear other opinions on this. @didier-wenzek @jarhodes314

In my view, the @skip field is different from the operation and payload fields because the iterator doesn't really care that the operation and payload fields are named as such. They could have been named anything like my_operation and my_payload as well. The user explicitly refers to those fields in the on_next target of the iterator as follows:

[next_operation]
iterate = "${.payload.operations}"
on_next = "apply_operation"
on_success = "twin_update"
on_error = "rollback"

[apply_operation]
operation = "${.payload.@next.item.my_operation}"
input = "${.payload.@next.item.my_payload}"
on_exec = "awaiting_operation"

But, the @skip field gets a special treatment by the iterator action during the iteration, just like the @next field is. And @next having that special @ prefix is what that prompted me to add that same prefix to @skip as well, so that all our internal fields have that consistency.

And @next having that special @ prefix is what that prompted me to add that same prefix to @skip as well, so that all our internal fields have that consistency.

Being consistent is appealing. We also need to avoid name clashes. Since, these two keywords can be injected by the iterator action in any operation workflow, I will go with @albinsuresh proposal.

@albinsuresh I don't think it makes sense to use @skip over skip. We previously used the @ prefix to denote special thin-edge.io property (e.g. in the registration syntax), however in the same payload we still use operation and payload...so the @skip does not look consistent (imho).
I'd be happy to hear other opinions on this. @didier-wenzek @jarhodes314

In my view, the @skip field is different from the operation and payload fields because the iterator doesn't really care that the operation and payload fields are named as such. They could have been named anything like my_operation and my_payload as well. The user explicitly refers to those fields in the on_next target of the iterator as follows:

[next_operation]
iterate = "${.payload.operations}"
on_next = "apply_operation"
on_success = "twin_update"
on_error = "rollback"

[apply_operation]
operation = "${.payload.@next.item.my_operation}"
input = "${.payload.@next.item.my_payload}"
on_exec = "awaiting_operation"

But, the @skip field gets a special treatment by the iterator action during the iteration, just like the @next field is. And @next having that special @ prefix is what that prompted me to add that same prefix to @skip as well, so that all our internal fields have that consistency.

With this explanation, then the @skip would be consistent then. Thanks for the thorough explanation.