Closed dmwesterhoff closed 2 years ago
Hey @dmwesterhoff could you post the full stack trace, please?
That seems like an issue actually more than a feature request - a full error will help speed up the diagnostics tomorrow.
Thanks a lot for flagging this!!
Sending from mobile, excuse me from verbosity and typos
It's a bug! It was meant to be a guard against a keyword argument not being present (L137).
This should be a check on whether the data kwarg exists in kwargs - accidentally, this is getting the value, and checking if it's falsy. This means even key=False would fail here (no good!).
As it's late here (8:48pm), I can make the fix tomorrow and cut a release with other merged enhancements -- if you have the bandwidth, please feel free to send a PR and I can review & expedite tomorrow.
@leandrodamascena need your review to this bugfix PR to add to today's release.
This issue is now closed. Please be mindful that future comments are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.
This is now released under 2.1.0 version!
Sorry for late reply, just seeing this now -- I was unsure of if this was unintended side effect (bug) or a feature :). Thanks for the swift resolution, much appreciated.
Use case
Trying to use
idempotent_function
in an "optional" manner. Example:When called like
echo(key=None)
will raiseRuntimeError
, even whenraise_on_no_idempotency_key
is set to FalseSolution/User Experience
Unless there is good reason not to respect the
IdempotencyConfig.raise_on_no_idempotency_key
value. Perhaps adding a similar parameter toidempotent_function
likeraise_on_no_data_keyword_argument
or something to that effect.Alternative solutions
No response
Acknowledgment