Provide a way for the developer to tell Mats whether this initiation/stage is idempotent or non-idempotent.
This could be the clue for Mats to enable inbox/outbox if available.
It would also aid in setting the "tone" of the log messages, i.e. "VERY BAD": It isn't very bad if the initiation or stage is idempotent.
(Also refer to #78, where this is set on the entire Stage via StageConfig)
For an initiation, this could denote that a failure to get the messages out will be handled by a later run: If e.g. a message is initiated every 10 minutes to grab batches of messages, it doesn't matter much if one of the slots fails. As such, the severity of the loglines could be reduced.
(Is it also a mark of whether an initiation is "important"? That is, a "GET style" to present for users: In the extremely odd case where this fails, the world doesn't crash. Or is this already deduced by "nonPersistent"?)
For stages, it could control:
Whether to enable the inbox/outbox: If nonIdempotent, it means that this stage doesn't handle double deliveries: It might fail out on the second attempt (due to some entity already being inserted in a database, and it will fail the second round thus not send its outgoing messages).
What to write in the logs: If idempotent, the severity of the log lines could be reduced, from error-VERYBAD, to warn-"Sorry".
Provide a way for the developer to tell Mats whether this initiation/stage is idempotent or non-idempotent.
This could be the clue for Mats to enable inbox/outbox if available.
It would also aid in setting the "tone" of the log messages, i.e. "VERY BAD": It isn't very bad if the initiation or stage is idempotent.
(Also refer to #78, where this is set on the entire Stage via StageConfig)
For an initiation, this could denote that a failure to get the messages out will be handled by a later run: If e.g. a message is initiated every 10 minutes to grab batches of messages, it doesn't matter much if one of the slots fails. As such, the severity of the loglines could be reduced. (Is it also a mark of whether an initiation is "important"? That is, a "GET style" to present for users: In the extremely odd case where this fails, the world doesn't crash. Or is this already deduced by "nonPersistent"?)
For stages, it could control:
Relevant section in HTTP/1.1 spec wrt. "safe" and "idempotent" methods: https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html - section 9.1