-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Naive implementation of a backwards-compatible function_name
decorator
#202
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## dev #202 +/- ##
=======================================
Coverage 93.09% 93.09%
=======================================
Files 56 56
Lines 3243 3243
Branches 665 665
=======================================
Hits 3019 3019
Misses 137 137
Partials 87 87
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
5874780
to
cf6a425
Compare
function_name
function_name
decorator
class LegacyBluePrint(TriggerApi, BindingApi): | ||
pass | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
notice this doesn't inherit from SettingsApi :)
Hi David @davidmrdavid , wonder what error customer has seen from this breaking change? and is this starting to happen just recently? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - thanks for the fix. :)
@gavin-aguiar: I noticed the tests are failing, any ideas on what happened? |
This PR (https://github.com/Azure/azure-functions-python-library/pulls?q=is%3Apr+is%3Aclosed+settingsapi) seems to have made a breaking change prevent DF BluePrints from using the
function_name
decorator in versions < 1.2.8 ofazure-functions-durable
.This PR mitigates that breaking change by creating a backwards compatibility layer that allows anything that inherits from
TriggerAPI
to continue usingfunction_name
. I also keep the implementation ofSettingsApi
'sfunction_name
to be the same as thisTriggerAPI
backwards compat layer by unifying the implementations under a_function_name
private method inherited fromDecoratorAPI
. The approach isn't perfect, but I think it's sufficiently clean given the circumstances.I also added a test to validate this worked