为何Snowpark存储过程超时时长仅3600秒？默认参数为172800秒

• 存储过程内部的语句级超时配置：如果你的存储过程里，某条SQL语句单独设置了STATEMENT_TIMEOUT_IN_SECONDS = 3600，这个局部参数会直接覆盖用户、会话及仓库层面的默认值。一旦这条语句执行满3600秒，就会触发超时，进而终止整个存储过程。
• 仓库资源不足或竞争：如果仓库规格太小，或者运行时被其他任务抢占了资源，存储过程的执行会被拖慢，甚至陷入资源等待状态。这种情况下，系统可能会触发隐性的资源耗尽终止逻辑，表现为3600秒的“超时”，本质是资源不够导致的执行停滞。
• Snowpark客户端的独立超时设置：调用存储过程的Snowpark SDK（比如Python或Java版本）自身有超时配置，比如Python中调用存储过程时指定的超时参数，这个客户端层面的超时会优先于服务端的STATEMENT_TIMEOUT_IN_SECONDS。如果客户端超时设为3600秒，到点就会主动终止请求，跟服务端的默认设置无关。
• 事务超时限制：如果存储过程包含事务操作，Snowflake的事务超时默认值可能是3600秒（不同版本或配置略有差异），这个限制独立于语句超时。当整个事务执行超过这个时长，系统会直接终止事务，表现为存储过程超时。
• 调度系统的任务优先级终止：Snowflake后台调度可能会对长时间运行的任务做优先级调整，若你的存储过程被标记为低优先级，可能会在运行3600秒后被强制终止，这种情况也会呈现为超时。

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