Logic App Standard（有状态）应用内连接器执行存储过程无返回异常

可能原因及排查方向 #

• 结果集处理机制差异：Logic App的SQL连接器和Function对大结果集的处理逻辑不同，SQL端执行完成后（所以Application Insights显示成功），连接器可能在序列化/读取大量数据时卡住，ServiceProviders.Sql.QueryTimeout只管控SQL查询执行阶段的超时，管不了后续的数据处理环节。
• 有状态模式的会话限制：有状态Logic App的工作流会话有内存或数据传输上限，结果集过大时会触发限制，导致处理停滞，而非真正的执行超时。
• 连接器配置缺失：默认情况下，Logic App SQL连接器可能未开启大结果集分页，一次性加载全量数据容易出问题。

具体解决方法 #

1. 开启结果集分页
   在执行存储过程的连接器动作里，打开高级设置，启用分页功能，设置合适的页面大小（比如1000条/页），让连接器分批读取结果，避免一次性加载大量数据导致内存溢出或处理卡住。

2. 调整工作流内存限制
   修改host.json配置，增加有状态工作流的内存分配，示例如下：

   "extensions": {
     "workflow": {
       "settings": {
         "RuntimeMemoryLimitInMB": 2048
       }
     }
   }
   

   根据实际数据量调整内存数值，保证能容纳分批次处理的数据量。

3. 排查特殊数据类型
   确认存储过程返回的结果集是否包含大文本、二进制等特殊数据类型，Logic App连接器对这类数据的序列化支持不如Function灵活。可以临时修改存储过程，只返回普通字段测试，排查是否是数据类型导致的问题。

4. 临时切换无状态模式测试
   把工作流改成无状态模式尝试执行，若能正常返回数据，说明是有状态模式的会话限制导致的问题，再针对性调整有状态的配置参数。

5. 配置动作级超时
   除了全局的ServiceProviders.Sql.QueryTimeout，还要在连接器动作的高级选项里设置超时参数，确保覆盖整个动作（包括结果读取）的耗时，避免因数据处理慢导致的停滞。

内容的提问来源于stack exchange，提问作者Sheikku