What is the issue?
Every synchronous and asynchronous Azure managed interceptor construction performs a distribution metadata lookup to determine the SDK version.
What is the impact?
The lookup adds filesystem and package-metadata work to client and worker construction. It is a small cost per instance, but it appears on cold startup and is repeated when applications create multiple clients or workers.
Details about the issue including code reference
Relevant code:
|
def __init__( |
|
self, |
|
token_credential: TokenCredential | None, |
|
taskhub_name: str, |
|
worker_id: str | None = None): |
|
try: |
|
# Get the version of the azuremanaged package |
|
sdk_version = version('durabletask-azuremanaged') |
|
except Exception: |
|
# Fallback if version cannot be determined |
|
sdk_version = "unknown" |
|
user_agent = f"durabletask-python/{sdk_version}" |
|
self._metadata = [ |
|
("taskhub", taskhub_name), |
|
("x-user-agent", user_agent)] # 'user-agent' is a reserved header; use 'x-user-agent' |
|
if worker_id is not None: |
|
self._metadata.append(("workerid", worker_id)) |
|
super().__init__(self._metadata) |
|
def __init__(self, token_credential: AsyncTokenCredential | None, taskhub_name: str): |
|
try: |
|
# Get the version of the azuremanaged package |
|
sdk_version = version('durabletask-azuremanaged') |
|
except Exception: |
|
# Fallback if version cannot be determined |
|
sdk_version = "unknown" |
|
user_agent = f"durabletask-python/{sdk_version}" |
|
self._metadata = [ |
|
("taskhub", taskhub_name), |
|
("x-user-agent", user_agent)] |
|
super().__init__(self._metadata) |
Both interceptor constructors call importlib.metadata.version for durabletask-azuremanaged and provide an unknown fallback on failure.
A potential or proposed solution
Resolve the SDK version once in a module-level cached helper and reuse it for every interceptor. Preserve the current unknown fallback and user-agent format.
What is the issue?
Every synchronous and asynchronous Azure managed interceptor construction performs a distribution metadata lookup to determine the SDK version.
What is the impact?
The lookup adds filesystem and package-metadata work to client and worker construction. It is a small cost per instance, but it appears on cold startup and is repeated when applications create multiple clients or workers.
Details about the issue including code reference
Relevant code:
durabletask-python/durabletask-azuremanaged/durabletask/azuremanaged/internal/durabletask_grpc_interceptor.py
Lines 25 to 42 in 55d8e0b
durabletask-python/durabletask-azuremanaged/durabletask/azuremanaged/internal/durabletask_grpc_interceptor.py
Lines 83 to 94 in 55d8e0b
Both interceptor constructors call importlib.metadata.version for durabletask-azuremanaged and provide an unknown fallback on failure.
A potential or proposed solution
Resolve the SDK version once in a module-level cached helper and reuse it for every interceptor. Preserve the current unknown fallback and user-agent format.