-
Notifications
You must be signed in to change notification settings - Fork 71
Naive implementation of a backwards-compatible function_name decorator
#202
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
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_namefunction_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? |
vrdmr
left a comment
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_namedecorator 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
TriggerAPIto continue usingfunction_name. I also keep the implementation ofSettingsApi'sfunction_nameto be the same as thisTriggerAPIbackwards compat layer by unifying the implementations under a_function_nameprivate 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