feat: Add support for new Durable Python SDK#353
Conversation
andystaples
changed the title
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
…le_package, add v2 converter tests - Revert version bump 2.3.0b2 -> 2.3.0b1 (handled by release process) - Move non-essential logs to debug and strip all but module-selection-path logs - Replace try/except with if/else for v1/v2 detection logs - DurableClientConverter uses get_durable_package() instead of plain import - Reorder registration so v2 is the if and legacy is the else fallback - Add tests for the v2 converters and register_durable_converters/get_durable_package
| _logger.debug("`azure.durable_functions` package not found.") | ||
| return None | ||
|
|
||
| if hasattr(durable_functions, 'version') and durable_functions.version.startswith("2."): |
There was a problem hiding this comment.
The current SDK does not expose azure.durable_functions.version. This will always log v1 package is used right?
There was a problem hiding this comment.
AFD V2 will expose this property
There was a problem hiding this comment.
Correct — with the current published SDK there's no version attribute, so it takes the else branch and logs v1.x, which is the intended behavior today. The version-based check is forward-compat: once the v2.x (Durable Task) SDK ships exposing version = "2.x", the same code will detect and log v2.x and register the new converters. It's a debug-only log, so no functional impact either way.
| import azure.durable_functions as durable_functions # noqa | ||
| except ImportError: | ||
| _logger.debug("`azure.durable_functions` package not found.") | ||
| return None |
There was a problem hiding this comment.
In which case this will return none? Won't a durable app always has the SDK installed?
There was a problem hiding this comment.
Good question — the None path is reachable and intentional in two cases:
-
Non-durable apps (the common case).
register_durable_converters()runs at import ofazure.functionsfor every app. The majority of apps don't haveazure-functions-durableinstalled, soget_durable_package()returnsNoneand registration is a deliberate no-op. -
A user references a durable decorator without the SDK installed. The durable decorators (
orchestration_trigger,entity_trigger,activity_triggeronTriggerApi;durable_client_inputonBindingApi) are defined unconditionally in the baseazure-functionslibrary and inherited by everyFunctionApp/Blueprint. So a user can reference@app.orchestration_triggereven without the SDK present. In that case_get_durable_blueprint()getsNoneand raises the explicit "please installazure-functions-durable" error, instead of surfacing a confusingImportError/AttributeError.
So a correctly-configured durable app will always have the SDK, but None is the right guard for both the non-durable-app import path and the misconfigured-durable-app path.
- Register durable converters lazily on first _ConverterMeta.get() lookup instead of at azure.functions import time, avoiding a re-entrant import of the durable SDK (which imports azure.functions) - Move the DurableFunctions logger into _get_durable_blueprint and use debug - Group 'import logging' with the other stdlib imports in durable_functions.py - Add deferred-registration tests in test_meta.py
|
Thanks @gavin-aguiar for the review. |
3 participants
No description provided.