Exception thrown when passing large input to Orchestrator function

[nials-relevant]

Describe the bug I'm building a durable function in TypeScript. This function will take a big JSON file.

• Axios has a default size limit of 2 megabytes.
• This issue has been addressed once before in this issue: #93 where it was determined that azure limits requests to 100 megabytes, but only the maxContentLength was changed.
• maxContentLength is for the response, maxBodyLength is for the request (documentation).

Investigative information

Durable Functions extension version: [2.*, 3.0.0) durable-functions npm module version: 2.1.1 Language (JavaScript/TypeScript) and version: 4.0.0 Node.js version: 16.19.0

If deployed to Azure App Service

Timeframe issue observed: Function App name: Function name(s): Region: Orchestration instance ID(s): If you don't want to share your Function App name or Functions names on GitHub, please be sure to provide your Invocation ID, Timestamp, and Region - we can use this to look up your Function App/Function. Provide an invocation id per Function. See the Functions Host wiki for more details.

To Reproduce Steps to reproduce the behavior:

Go to '...' Click on '....' Scroll down to '....' See error While not required, providing your orchestrator's source code in anonymized form is often very helpful when investigating unexpected orchestrator behavior.

Expected behavior A clear and concise description of what you expected to happen.

Actual behavior A clear and concise description of what actually happened.

Screenshots If applicable, add screenshots to help explain your problem.

Known workarounds Provide a description of any known workarounds you used.

Additional context

Development environment (ex. Visual Studio) Links to source Additional bindings used Function invocation IDs

[davidmrdavid]

Hi @nials-relevant.

I just responded to your PR, though perhaps it's best if we continue our discussion here to keep the PR thread specific to PR feedback. In short, the limitation on large inputs placed by axios has been left in place to help indirectly enforce that inputs to Durable Functions APIs must be relatively small. This is because we serialize and persist the explicit inputs and outputs to DF APIs (like Activities or sub-orchestrators) which means that if users are not careful, they can very quickly run out of memory. Usually, the best practice is to keep inputs and outputs small, but to generative "arbitrarily" large objects inside Activities if needed. Are you familiar with these Durable Functions best practices? It's not front and center in the documentation at this time, although that's something we're working to improve in the near future.

Can you please tell me a bit more about your scenario? What kind of large inputs are you looking to provide, and how large are they?

[nials-relevant]

Hi @davidmrdavid.

We use a durable function to receive records to be processed for CRUD operations, and sometimes we can manage large JSON files due to the nature of the application.

[davidmrdavid]

@nials-relevant: could you share a rough estimate of how large the JSON files are? I'm just trying to determine if the problem is that the axios limit is overly constraining (i.e the limit is too small), or if the JSON files are too big.

If it's the former, then I would be willing to reconsider a different limit. However, if the JSON inputs are simply very large, then I'm not ready to remove the limit at this time. To deal with large data, the best practice for Durable Functions is to materialize the data only within Activities, so that inputs and outputs to DF APIs can be kept small. I'd be happy to provide more detail on this guidance if you need it :)

[htshaugh]

davidmrdavid, I work with Nials and wanted to follow up on this post. The typical operation is small (100k or less) but occasionally we may have documents that exceed the 2mb limit. We think 5mb would be a safe upper limit for us. Thanks!

[davidmrdavid]

Thanks @htshaugh. 5mb gives me a good starting point. @nials-relevant: could you please update your PR to adjust that upper limit? Thanks!

[nials-relevant]

@davidmrdavid, I updated the PR.

[davidmrdavid]

Thanks @nials-relevant. I'll be reviewing the PR shortly

[davidmrdavid]

This should have been released as part of the latest npm payload