【Azure Function App】升级 Python 运行时 3.9 到3.10 后遇见的问题

简介: Azure Functions 升级 Python 3.9→3.10 时,仅改 Portal 配置易致故障:一是复用旧版依赖引发加载超时(Exit 137);二是 typing_extensions 与实际运行时(如 3.13)不兼容,抛 AttributeError。须重装依赖、锁定 typing_extensions≥4.12,并验证真实 Python 版本。

问题描述

Azure Function 原来运行在 Python 3.9。由于 Python 3.9 即将停止维护,需要升级到 Python 3.10。

第一次升级时,只是在 Function App 页面中进入Settings → Configuration → General settings,将 Python 版本从 3.9 修改为 3.10。

Function App 表面上可以正常启动,但绑定的 Service Bus topic-subscription 消息不再被正常消费。

观察到的主要错误如下:

Loading function failed. ExceptionType: System.TimeoutException
Timeout value of 00:30:00 exceeded by function 'Functions.func1'
Executed 'Functions.func1' (Failed, Duration=1800022ms)
Message processing error (Action=ProcessMessageCallback, EntityPath=<topic-name>/Subscriptions/<subscription-name>)

后台日志中还可以看到 Python Worker 被强制终止:

The process with PID XXXX (language worker) was forcefully terminated.
Exit code: 137 (SIGKILL)

之后重新部署了新的 package,但消息仍然无法消费。这次错误变成了函数加载阶段立即失败:

[Error] Executed 'Functions.func1' (Failed, Duration=1ms)
Exception: AttributeError: attribute '__default__' of 'typing.ParamSpec' objects is not writable

堆栈中可以看到错误发生在导入azure.storage.blob的过程中,最终落到typing_extensions.py

File ".../azure/storage/blob/_blob_client.py", line 22, in <module>
    from azure.core.tracing.decorator import distributed_trace
File ".../azure/core/tracing/decorator.py", line 37, in <module>
    P = ParamSpec("P")
File ".../typing_extensions.py", line 1474, in _set_default
    type_param.__default__ = None
AttributeError: attribute '__default__' of 'typing.ParamSpec' objects is not writable

问题解答

这次问题主要分成两个阶段。

1. 只修改 Function App 运行时版本,依赖包没有重新构建

第一个错误的重点是:

System.TimeoutException
Duration=1800022ms
exit code 137 / SIGKILL

这说明函数并不是业务代码执行慢,而是在 Worker 加载函数时卡住,最终被 Host 强制终止。

常见原因是应用使用WEBSITE_RUN_FROM_PACKAGE方式部署,zip 包中的 Python 依赖是在旧的 Python 3.9 环境下安装或编译的。

只在 Portal 中把运行时改成 Python 3.10 后,云端解释器变成了 3.10,但包里的原生依赖仍可能是 3.9 的构建产物,例如grpcioprotobufcryptography等,从而导致函数加载异常或超时。

建议处理方式:

  • 在本地准备目标 Python 版本环境,例如 Python 3.10。
  • 删除旧依赖包,不复用 Python 3.9 环境下生成的 package。
  • 在 Python 3.10 环境下重新安装依赖:
pip install --upgrade pip
pip install -r requirements.txt
  • 重新打包并部署。

2.typing_extensions与实际 Python 运行时不兼容

第二个错误的重点是:

AttributeError: attribute '__default__' of 'typing.ParamSpec' objects is not writable

如果堆栈中出现类似下面的路径:

/azure-functions-host/workers/python/3.13/...

说明当前实际运行环境可能涉及 Python 3.13。旧版typing_extensions与 Python 3.13 中typing.ParamSpec.__default__的行为不兼容,可能在导入azure.storage.blobazure.core.tracing.decorator等依赖时直接失败。

建议处理方式:

  • requirements.txt中显式指定较新的typing_extensions版本:
typing_extensions>=4.12.0
  • 重新安装依赖并重新打包:
pip install --upgrade pip
pip install -r requirements.txt
  • 部署后检查 Function App 实际 Python 运行时版本,确认它和预期一致。
  • 如果目标是 Python 3.10,需要确认配置没有实际运行到 Python 3.13。
  • 再次验证函数是否可以正常加载,以及 Service Bus topic-subscription 中的消息是否可以正常消费

总结

Azure Functions 升级 Python 运行时时,不建议只在 Portal 中修改 Python 版本。

更稳妥的顺序是:

准备目标 Python 版本环境
→ 重新安装依赖
→ 重新打包
→ 部署到 Staging Slot 验证
→ 确认实际运行时版本
→ Swap 到生产环境

这次排查中,两个关键点分别是:

  • System.TimeoutExceptionDuration=1800022msexit code 137:优先检查是否复用了旧 Python 版本构建出来的依赖包。
  • AttributeError: attribute '__default__' of 'typing.ParamSpec' objects is not writable:优先检查typing_extensions版本,以及实际运行的 Python 版本是否符合预期。

参考资料

更新 Azure Functions 中的语言堆叠版本 :https://docs.azure.cn/zh-cn/azure-functions/update-language-versions?tabs=azure-portal%2Clinux&pivots=programming-language-python

attribute '__default__' of 'typing.ParamSpec' objects is not writableon Python 3.13 :https://github.com/python/typing_extensions/issues/404

相关文章
|
4天前
|
云安全 人工智能 运维
阿里云SecOps Agent,全新安全跨产品执行体验
自然语言驱动 云安全中心/WAF/CFW/ 等多款安全产品联动
1596 2
|
2天前
|
人工智能 定位技术 SEO
我学 GEO 第 15 天:终于知道AI GEO该如何做?
我是暴走的莉莉酱,边旅行边研究AI GEO的数字游民。专注普通人如何提升“AI可见度”——让AI在回答用户问题时准确识别、理解并推荐你。不讲玄学,只做可测、可调、可持续的GEO实践。
355 123
|
4天前
|
机器学习/深度学习 人工智能 调度
🐴 HappyHorse 1.1 现已上线阿里云百炼!快来查收模型使用指南,现在调用享 6 折~
HappyHorse 1.1 是新一代视频生成大模型,全面升级动态表现力、角色一致性、指令遵循、视觉质感与音画协同能力。支持I2V/T2V/R2V三类生成,适配短剧、电商广告、品牌营销等场景,提供高质、流畅、可控的AI视频生产力。
598 4
🐴 HappyHorse 1.1 现已上线阿里云百炼!快来查收模型使用指南,现在调用享 6 折~
|
15天前
|
缓存 测试技术 API
Qwen 3.7 Plus 与 Max 实测:性价比与多模态能力差异解析(2026)
2026 年 6 月 1 日,阿里悄无声息地发布了 Qwen 3.7 Plus,距 Qwen 3.7 Max 上线刚好 11 天。同样的 1M 上下文,同样的 35 小时自治上限。但价格才是头条:Plus 是 0.40/M输入,Max是 2.50/M——便宜约 6 倍——并且还能看图、看视频。Vision Arena 上 Plus 已经排到 #16。所以这周真正值得讨论的问题不是”要不要为视觉能力买单”,而是”Max 凭什么用 6 倍价格换来 2 个百分点的 benchmark 领先”。
|
16天前
|
JavaScript 定位技术 API
CodeGraph 爆火:编程 Agent 需要的不是更多上下文,而是一张提前画好的代码地图
CodeGraph 是一款爆火的本地代码智能工具,通过 tree-sitter 解析 AST 构建结构化知识图谱(存于 SQLite),为编程 Agent 提前生成“代码地图”。它显著降低 Agent 在中大型项目中的探索成本——实测工具调用减少71%、Token 降57%、速度提升46%,支持19+语言及主流框架路由识别,完全离线、无需 API Key。
924 12
CodeGraph 爆火:编程 Agent 需要的不是更多上下文,而是一张提前画好的代码地图
|
8天前
|
缓存 人工智能 运维
GLM 5.2自托管全流程实战:硬件选型、vLLM/SGLang部署与成本盈亏测算
2026年智谱发布GLM 5.2超大混合专家模型,区别于以往仅开放API的闭源大模型,该模型权重以MIT开源协议对外发布,企业与开发者可完整下载、本地审计、私有化部署,实现数据不出环境、自定义微调、自主调度推理资源。GLM 5.2拥有753B总参数,原生支持百万级上下文窗口,在代码生成、长文档推理、数学逻辑等多项基准测试中对标国际顶尖商用模型,是首款可完整自托管的前沿代码向大模型。
683 0
|
3天前
|
消息中间件 人工智能 Kafka
AI 时代,实时入湖正在告别 ETL:从 Kafka 到 Iceberg 的架构减法
本文围绕“零 ETL”这一趋势,讨论流数据入湖为什么需要做架构减法,并结合 Kafka × Table Bucket 的实践,分析一种将通用入湖能力前移到消息与表存储链路中的方案,如何在降低复杂度的同时,兼顾实时性、一致性、Schema 演进、CDC 语义与开放生态兼容。
193 121
|
3天前
|
人工智能 监控 前端开发
Electron 监控:让桌面 Agent 监控触手可及
一行代码实现Electron桌面端全景监控,自动还原崩溃现场、预警内存泄漏、全链路追踪、 SSE流式响应与交互埋点,让 AI 助手运行状态清晰可见,助力快速恢复稳定与流畅。
185 125
|
11天前
|
人工智能 自然语言处理 算法
阿里云百炼Qwen 3.7 Plus与Max实测全解:性价比与多模态能力、成本深度对比
2026年,阿里云百炼平台推出的Qwen 3.7系列成为企业与开发者落地AI应用的核心选择,其中Qwen 3.7 Max与Plus作为两大旗舰版本,定位差异显著:Max是纯文本推理旗舰,专注高强度智能体与复杂逻辑任务;Plus则是多模态全能版,在保留强大文本能力的同时,补齐图像、视频理解能力,且价格大幅降低。本文基于2026年最新实测数据,从核心参数、文本能力、多模态能力、智能体表现、性价比与场景选型六大维度,全面解析两款模型的差异,为用户提供精准选型参考。
552 0