4 ms·

Ok, yes - I'm with you. I now realise how this statement could be misleading. > To mark a function as idempotent, simply wrap it with the idempotent function.

Ok, yes - I'm with you. I now realise how this statement could be misleading. > To mark a function as idempotent, simply wrap it with the idempotent function. When initially writing it, I thought it was a "given" that the wrapped functions are the responsibility of the developer. Now I realise this can also be interpreted as "we make your functions idempotent". Thanks for the detailed breakdown. We will work on the docs to make it clearer.

CipherThrowaway 3y ago
If that was the assumption, then this whole thing makes even less sense. If your operation is already idempotent in its implementation, then wrapping it with this function is the last thing you'd want to do. By introducing at-most-once semantics on top of the call, it would defeat the point of making the operation idempotent to begin with. The scenario where you'd want to use this `tryOnce` policy is probably the following: 1. You have an operation that is not idempotent and can't be made idempotent, for whatever reason. 2. You would prefer the failure mode of that operation to be that the effect doesn't take place, rather than that the effect takes place more than once. BTW, you don't need to have an answer for everything. I don't think there has been any miscommunication or misunderstanding of the docs. I think people in this thread, including myself, have accurately identified that you haven't fully thought some of this stuff through. That's fine and normal for a product in this stage, but not being willing to admit it is less of a good sign. Good luck with the startup.
- lunarcave 3y ago
  > If your operation is already idempotent in its implementation No, this is not at all what I meant. I don't think there's any value in introducing at-most once semantics to an already idempotent function. I'm definitely not trying to have an answer for everything. But I guess we can leave it at that, at this point.

CipherThrowaway 3y ago

If that was the assumption, then this whole thing makes even less sense. If your operation is already idempotent in its implementation, then wrapping it with this function is the last thing you'd want to do. By introducing at-most-once semantics on top of the call, it would defeat the point of making the operation idempotent to begin with. The scenario where you'd want to use this `tryOnce` policy is probably the following: 1. You have an operation that is not idempotent and can't be made idempotent, for whatever reason. 2. You would prefer the failure mode of that operation to be that the effect doesn't take place, rather than that the effect takes place more than once. BTW, you don't need to have an answer for everything. I don't think there has been any miscommunication or misunderstanding of the docs. I think people in this thread, including myself, have accurately identified that you haven't fully thought some of this stuff through. That's fine and normal for a product in this stage, but not being willing to admit it is less of a good sign. Good luck with the startup.

lunarcave 3y ago
> If your operation is already idempotent in its implementation No, this is not at all what I meant. I don't think there's any value in introducing at-most once semantics to an already idempotent function. I'm definitely not trying to have an answer for everything. But I guess we can leave it at that, at this point.