Which field uniquely identifies a state? The "id" or the "name"?

[giorgosera]

Hi there, which of the two fields id or name uniquely identifies a state?

In the JSON schema here I can see that there is an id field on a state and the description says Unique State id. and for the name it just says State name.

However, when I go to the spec docs here I can see that the name description says "Unique state name". Also, there is no mention of the id field there.

• So which one should be used to uniquely identify a state?
• Also, is it better to look at the JSON schema for an up-to-date documentation of the fields?

Thank you very much

[cdavernas]

@giorgosera My understanding of it is that state id is an obsolete artifact of a previous version of the spec. In Synapse and other runtimes, we uniquely identify states thanks to their name, which is a required property, and avoid the useless overhead for users that is to set the id property too, which is therefore useless.

@tsurdilo Can you please confirm/infirm? Shouldn't we do a PR for getting rid of that confusing property, anyways?

[tsurdilo]

got it, we then should add example of that in our spec doc

[tsurdilo]

also think that we should add either as top-level prop or extension (supplied by us or runtimes i dont care) ability for user to say what should happen if multiple instsances with same business level id (key) are tried to be created by client

(what should happen in terms of "allow" "not allow", "???")

[cdavernas]

also think that we should add either as top-level prop or extension (supplied by us or runtimes i dont care) ability for user to say what should happen if multiple instsances with same business level id (key) are tried to be created by client

@tsurdilo IMHO, key should be unique if specified, thus other instances with similar key should fault. IMHO, this should be the only allowed behavior, otherwise there's no purpose to using the key

[ricardozanini]

This is what key is for. As was demonstrated by @mswiderski in another issue.

@cdavernas do you have the link for this issue? We are currently ignoring key in our implementation. I mean, if id is not defined, it's the identification of the workflow definition. But rather than that, it means nothing to us internally.

[tsurdilo]

@cdavernas lets talk offline or in weekly meet. think of use case where you have "entity" workflows meaning the execution can represent an atomic operation and user does not want to have more than one wf instance ood this entity. another use case is completion, where user only wants to allow an entiry to be processed if previous attempt to do so had failed