Other posts have touched on parts of this topic separately. AIP FDE, AIP Assist, and my own documentation reviews cannot come up with definitive answers. I am fine with running things through Automate when needed, but I would like to definitively know when that needs to occur and if AIP Logic Functions vs TSV2 code functions in deployed mode will be needed.
An answer here would be great, but ideally, this matrix would be published in the documentation so AI FDE can know it.
Summary
I’m looking for a comprehensive reference that documents the timeout limits for Foundry functions across all execution modes, languages, and calling contexts. This information is partially surfaced in the deployed function configuration panel but is not available in the official documentation, making it difficult to architect solutions that involve long-running function calls.
Background
I’m working with a TypeScript v2 repository that contains a mix of lightweight query functions and heavyweight orchestration functions (the latter call multiple AIP Logic agents in parallel and can take 330+ seconds). While configuring my deployed functions, I noticed the configuration panel states that even deployed functions have a 280-second timeout limit unless called by Automate, at which point the configurable timeout (e.g., 600s) applies.
This information does not appear in the official documentation for Deploy functions or elsewhere, and I could not find equivalent information for serverless functions or AIP Logic functions.
What I’m Requesting
A timeout matrix that documents the following dimensions:
| Dimension | Values to Cover |
|---|---|
| Function Type | TypeScript v1, TypeScript v2, Python, AIP Logic |
| Execution Mode | Serverless, Deployed, N/A (for Logic) |
| Caller / Execution Context | Workshop, AIP Logic (as caller), Automate, OSDK / External App, API Gateway, Action (user-initiated), Function-to-Function call, Workflow Builder preview/test |
| Timeout Configurable? | Yes / No |
| Timeout Limit | Specific value in seconds |
Specific Questions
-
Serverless functions (TS v2 / Python): What is the fixed timeout limit? Does it vary by caller (e.g., Workshop vs. Automate vs. OSDK)?
-
Deployed functions (TS v2 / Python): The configuration panel indicates a 280s limit unless called by Automate. Is this accurate? Are there other callers that also respect the user-configured timeout beyond 280s?
-
AIP Logic functions: These do not have a configurable timeout setting. What are the timeout limits when:
- Called directly from Workshop (e.g., as a widget event or backing a variable)?
- Called from Automate (e.g., triggered by a condition or schedule)?
- Called from another function (e.g., via
client(myLogicFunction).executeFunction(...)in TS v2)? - Executed from the Workflow Builder test/preview panel?
-
Nested / chained calls: If Automate calls a deployed function (with extended timeout), and that function calls an AIP Logic function, does the Logic function inherit the extended timeout context? Or does it fall back to its own default limit?
-
Are there any plans to make AIP Logic timeouts configurable? For complex multi-agent orchestrations, the current fixed limits can be a constraint that forces architectural decisions (e.g., moving logic out of AIP Logic into deployed TS v2 functions solely for timeout reasons).
Why This Matters
Without this information, developers are forced to:
- Discover timeout limits through trial and error in production
- Make architectural decisions (serverless vs. deployed, Logic vs. pro-code, repo splitting) without understanding the constraints
- Over-provision deployed infrastructure “just in case” because the serverless limits are unknown
A single reference table would significantly improve the developer experience for anyone building long-running workflows, multi-agent orchestrations, or batch processing pipelines.