Can the instruction and input size limits be raised for large orders?

[thosakwe]

Currently, Shopify Functions can execute 11 million instructions max before failing with a RunOutOfFuel error.

What's the problem?

This poses a problem for large orders. When there are many cart lines in the input, JSON parsing alone can eat up a significant portion of that quota.

For example, many stores sell wholesale, where there are sometimes 80+ line items in the cart. In cases like this, the input JSON size can easily exceed 9KB. When you have 100 line items? 11KB and beyond.

I ran a script that runs my function with increasing number of cart lines, and stops when it hits 11M instructions. Here's a screenshot of the results (caps out at 34 cart lines):

To be fair, the specific function I was running here was in TypeScript, so I knew it wouldn't be super-efficient. However, I also wrote a barebones function in C++, using RapidJSON (the fastest C++ JSON library), and that capped at 69 cart lines.

It doesn't really even matter which parser you use, because even the fastest JSON parsers, such as LL(1) parsers, are O(n) in the worst case. And that's before the actual discount logic runs.

Why is this important?

There's no way to work around this, because discount functions have to query input.cart.lines in order to get product variant IDs to return in FunctionResult.targets.

As is, discount functions will always fail for large orders, so they're not usable for certain groups of merchants.

Potential solution

It would be amazing if the instruction limit were proportional to the number of cart lines, instead of having a one-size-fits-all limit.

Thank you for your consideration.

[nickwesselman]

Hello @thosakwe -- Thanks for the feedback and the detailed data! We have some plans around this which we hope to ship later this year. I will update this issue when it ships.

[nickwesselman]

Moving to General Improvements since this applies to most/all existing Function APIs.

[thosakwe]

Thanks, Nick! Looking forward to the update.

[thosakwe]

Update: I recently ported my Function to Rust, and made big performance gains.

Now, my function can handle 125 line items.

So, my recommendation to anyone reading this is to stick with Rust for functions on public apps, so that you can meet as many merchants' needs as possible.

[Hahlh]

Is there any update on this?

I would not consider this a possible improvement but actually feature breaking behavior that requires fixing.
These errors are difficult / time intensive to handle gracefully on the shop side and the instruction limit is very fast reached, specifically when working with bundles & customized products that consist of various product parts.

This behavior means that you can't trust the feature to work in a predictable manner. The input size might also vary in terms of other variables besides the raw number of line items.
Trying to force a cart size limit in the shop once bundles are used also doesn't feel like a good option.

We will rewrite the function in question in Rust, but aren't too optimistic about the improvement as cart size seems to be the strongest determinant of instructions used.

Is there any timeline for having this fixed or are there any updates in general?

[nickwesselman]

We have changes planned for Q1 to help with this.

Would be helpful to know what language you are working in, and what cart size is maxing out instructions for your use case.

Rust will always use fewer instructions than JavaScript, though we have some things a bit further out in the roadmap to narrow the gap.

[Hahlh]

We will provide you detailed limits for both JS and Rust in a bit.

We would be thankful, if you could let us know as soon as there is a more specific timeline as this is currently limiting the usability in production quite severely.

[thosakwe]

Update: My Rust port turned out to be too large once compiled (it's 384KB), so it's not a solution to the problem.

[Hahlh]

Thank you for the update, Tobe!

That is unfortunate.

[nickwesselman]

Are you using regular expressions by chance?

[thosakwe]

Hi Nick, we are not using regular expressions in this function.

I inspected the debug build using twiggy.

What's bloating the executable is the fact that our function has many JSON-serializable types, so serde is generating a lot of monomorphized code.

Hopefully, I can figure out a workaround here, and switch the function to Rust.

[thosakwe]

#425

[pjpollina]

Hi Nick, I'm working with Tobe. We've also noticed on exceptionally large errors, we also receive an InputSizeLimitExceededError.

We don't know how many line items it takes to trigger this at this time, as the input in the error report was truncated.

Tobe will follow up with more details about the RunOutOfFuel error and Rust function size issues.

Thanks!

[nickwesselman]

Our intention is to scale the input limit for large cart, along with the instruction limit. I'll update the feature request title to reflect this.

[sebabal]

Is there any update to this? We support a few Shopify Plus accounts (that pay quite a lot per month honestly) and we sold them the idea that Shopify can scale but when we have to go back and point to limitations like these, we look like a bunch of amateurs or that we basically lie about it, when they were able to handle stuff like this on Woocommerce just fine.

[PattyKovash]

Also looking for an update and solution to this issue as well. We are working with the cart transform function using Typescript.

[Hahlh]

@nickwesselman

Are there any updates regarding this?

Unfortunately, it doesn't seem that anything related to this crucial limitation is included in the roadmap:

https://shopify.dev/docs/apps/checkout#shopify-functions

This is still breaking lots of intended use cases.

[nickwesselman]

We understand the importance of this and have work in progress, but no release date to share at the moment.

[stevepsharpe]

Is there world where the August deadline is pushed back?

[nickwesselman]

If you mean Shopify Scripts end-of-life, it's already been extended to August 2025.

[stevepsharpe]

Oh, great. I must've missed that. I thought it was ending at the same time as the checkout migration. Thanks for clarifying.

[Hahlh]

That there is work in progress and that this is prioritized are the most crucial aspects for us, thank you for your fast response and for the letting us know, Nick!

[victorvilarocket]

the instruction limit should be increased... For instance, a simple JSON.parse of an array containing 3 json elements increases the number of instructions by a huge amount.

For B2B stores with many cart line items this limit is easily reached.

[thesunilyadav]

Hi there,
Has anyone discovered a solution or workaround for this issue yet?

Hi @nickwesselman Are there any plans to raise the maximum instruction count from 11 million instructions limit?

[Hahlh]

For the moment no real workaround seems to exist as far as our testing has shown.

The only option at the moment is optimization (e.g. porting the function to Rust, optimizing the code for instructions used, ...) and waiting for Shopify to come through and increase the limits or change what they actually count towards the limit (like bundle definitions on line items).

Even with Rust, the amount of line items possible is still very limited if the range of possible bundle combinations and therefore the cart items needing to be parsed become a bit more complex.

Compressing the bundle information on the line items also didn't seem to reap any benefits as the decompression & parsing in the function required for evaluation would eat up all the gains quite quickly.

Unfortunately, it seems like we will have to wait until Shopify introduces changes to the limit or the instruction calculation for both Rust & JavaScript.

[thesunilyadav]

Thank you @Hahlh for the information.

[meandillar]

@thesunilyadav

Hi there, Has anyone discovered a solution or workaround for this issue yet?

For our use case, we have a custom app that allows our users to create bundle discounts and free gifts like the good old days with Scripts. Using Scripts we could have up to around 80 bundles of various combinations within the script size limit. With a function we are restricted to around 20, both because of the instruction count limit and the metafield input size limit. The workaround for us involved splitting our active discount configurations across 5 Discount Nodes, giving us 5x the amount of instructions. What this meant for us:

• creating 5 Discount Nodes instead of 1
• fetching and parsing 5 different metafields within the app to retrieve our active discount configurations and merging them together to give the impression of a single group of discounts on the app frontend
• splitting the active discounts back into 5 separate metafields again when updating, making sure that each is within the metafield input size limit
• slower app because of the extra work

And then there was another big problem - having to find a way of adding some extra discount logic after the previous discounts had been applied. There is no real way to set the order of execution for functions, so if you want to apply a discount after some other discounts have been calculated you can put it in the same function right? But what if you have 5 discount function executions and you only want this extra discount logic running on the 5th function execution? I found that upon creating the 5 Discount Nodes, the last to be created would consistently run last. So that's what we've had to do to make it work. So far so good but hopefully it doesn't change because our system will break. Attempt at your own risk lol.

Now we can run roughly the same number of discounts using functions as we did with Scripts. It has been an incredibly arduous journey for us to reach this point and we only wish we'd known about the Scripts deprecation date extension before embarking on this rollercoaster.

Hope that's useful!

[DominicVHill]

Hi guys, just stumbled across this limitation and it looks like it's completely breaking our B2B pricing use-case.

Does anyone know when the improvements will be rolled out?

We are handling prices using the shopify Metafield and Cart Transformer API. Unfortunately when the function bugs out, we get the incorrect price in the cart.

[andre-beeclever]

We had the same problem. We ended up rewriting the whole logic in rust, which at least increased the limit to one that is acceptable.

[RobinKemna]

We ran into the same limitations quiet recently and now need to rewrite from TS to Rust - hitting that limitation for our custom expand bundle function.

[DominicVHill]

Yeah we've just moved to Rust which has helped a lot (15 products to 47).

We're hitting inputsizelimit errors now due to the json size (one of our product metafields has a json structure which is killing the cart). We're trying to trim down all the keys and extra characters to try and improve it again.

[thosakwe]

Over the past 10 months, it’s become clear that the 11M instruction count limit affects not just large orders but also functions that pull a lot of data.

Take a discount function as an example: if it checks if a product is in several collections, the input size increases along with the line items. Because of the required JSON parsing, you're likely to hit the instruction limit quickly, even if there aren't many items in the cart.

Instead of linking the limit to the number of line items, it might be better to base it on the size of the input. This way, the limits can stay tight (to avoid overloading the server) but won’t be too restrictive.

If Shopify Functions are going to take over from scripts, adjusting how they scale could make this transition smoother.

EDIT: Another possible option is to increase the number of Functions a store can create (for example, more than 5 discount functions, or more cart transforms), you can still have strict limits on the instruction count, but merchants will be able to create more Functions to cover all their bases.

[schmidtc63]

Any update on this for JavaScript functions? We are about to bring wholesalers on line and this is preventing that. But it's not just wholesalers. We are stuck at around 33 items in the cart right now. On sale days, that's nothing.

I am looking at the previous comments and seeing lots of promises about "later this year" in 2023 and "changes planned for q1"... We're in Q3 now and no fix in sight. Please update...

[ahorner1117]

I am certainly not relieved to have scrolled through this entire forum and see that I am not the only one still running into this problem. I am working on a high-traffic site and my javascript discount app is pretty much useless because at all times of the day, there is roughly a minimum of 70 products in different carts and hitting the InstructionCountLimitExceededError. Has anyone found a workaround? I see that people mention switching to Rust however with the number of line-items this store has at all times, Rust seems useless also.

[SidNewman]

Looks like I've got to move to Rust

[seandogg]

Also stuck. Migrating to Rust tonight apparently :(

[Ulset]

Bumping this aswell, the cap should really be increased or at the very least be based on the number of items in the cart.

[overallduka]

For those who is moving to Rust, it's not yet the optimal result, I am using Rust and JS extensions.. the performance of Rust is better and allows more flexibility, but when cart items grows it often (1% rate error) generates these 2 types of errors:
InputSizeLimitExceededError
InstructionCountLimitExceededError

[seanorfila-twp]

Be sure to uninstall your JS function once you have your Rust extension installed.

I wasn't able to get any line item gains until the javascript version was uninstalled

[MuraviovVladyslav]

@nickwesselman hey, are you going to share any more updates on this issue, except updates from Shopify CLI 3.67.0?

[nickwesselman]

Scaling based on cart is still in the roadmap.

[kylebuildsstuff]

Been seeing a lot more RuntimeError errors ever since upgrading to CLI 3.67.0 and @shopify/shopify_function 1.0.0, whereas before it was strictly just InputSizeLimitExceededError & InstructionCountLimitExceededError. For my product discount function at least I know I haven't changed anything but the dependency version.

The functions are still running well for the most part but is there any way I can get more insight into these errors without having to reach out to the merchant to ask them to share?

[kylebuildsstuff]

Received some reports related to my cart-transform and delivery-customization functions as well. After reverting back to 3.66.1 and 0.03 the functions seem to be working again as expected and the RuntimeError has stopped appearing.

[nickwesselman]

We have seen an increase in erroneous RuntimeError failures in the last ~24hr, but we've confirmed that they are unrelated to the Shopify CLI performance update. They should be mitigated at this point.