Limits

Every run has limits. A script cannot lift them from inside itself, and a script cannot catch the failure when it reaches one.

Time

A run has a wall-clock deadline, counted from the moment it starts. When it passes, the run stops and reports:

This script ran past its time limit of 60 seconds.

The deadline is checked at every pass of a loop (each, while, until) and at every call of a block. A tight loop, an endless loop and a block that calls itself are all stopped. sleep never waits past the deadline. A single long call into an object, such as a slow web request, is not interrupted part-way; the check happens when it returns.

Natural

while true
  set x to 1
end

Standard

while (true) {
  x = 1
}

The time limit is not an error that an error block or stoponerror deals with. It ends the run. If an earlier error was recorded and ignored before the deadline, the message names it, in the form The last error before it was on line 4 (expression): message. A loop that fails on every pass and never reaches its exit test therefore runs to the limit and tells you why.

A script that runs another with mash.scripts shares the caller’s clock. Running a second script never buys more time: the tighter of the two deadlines applies.

How long

Where the run starts	Foldr Cloud	Appliance
The editor’s Run button; a web request (a form, sign-in, a field lookup, a webhook)	60 seconds	300 seconds
A queued run (an automation, a schedule, a job)	60 seconds	60 seconds

On an appliance, a script setting named MASH_TIMEOUT, in seconds, replaces these. It must be a positive number below 3601, and a fraction rounds up to the next whole second. On Foldr Cloud the setting is ignored and the 60 seconds stand.

A queued run that passes its limit is recorded as Script timed out on 60 seconds.

Memory

A run may use 64 MB by default. A script that needs more stops with an out-of-memory error.

On an appliance, a script setting named MASH_MEMORY_LIMIT, in megabytes, raises the limit. It can only raise it: a smaller number is ignored. On Foldr Cloud the setting is ignored and 64 MB stands.

A script that runs another does not lower the caller’s limit. The nested run gets at least as much as its caller already had.

The settings are ordinary script settings, set where the script’s other settings are set. They are not variables in the script, and a script cannot change them while it runs.

Bulk actions

Some actions that a script can repeat in a loop have a cap per run, and a refill rate per organisation, so that one script cannot flood the system. When a cap is reached, the call is refused with a message that says why, for example this run has already reached its limit of 100 queued jobs. The refusal is a recorded error like any other, so the script carries on unless it checks.

Action	Per run	Per organisation
Queued jobs started by a script	100	a bucket of 500, refilling at one every 2 seconds
Emails sent through the platform’s mail	500 recipients	a bucket of 1,000, refilling at one every 5 seconds
A broadcast to people	100 recipients

The operator of an appliance can change the first two. The values above are the defaults, and Foldr Cloud uses them.

Foldr Cloud and appliances compared

	Foldr Cloud	Appliance
Time limit, interactive	60 s	300 s
Time limit, queued	60 s	60 s
MASH_TIMEOUT	ignored	honoured, up to 3600 s
Memory	64 MB	64 MB
MASH_MEMORY_LIMIT	ignored	honoured, can only raise
Network access to Foldr’s own internal addresses	refused	refused

The language itself is the same on both. The differences are limits, and which library objects are present. The library reference marks the objects that are available on an appliance only, or that need a licence or a feature.

Staying inside the limits

• Take a fixed batch of work per run when you process something large, such as a whole folder, and let a schedule start the next run.
• Use stoponerror = true so a failing loop stops at its first error instead of failing ten thousand times until the time limit.
• Prefer a generator block with take to build a list you only need the start of. See Blocks and calls.
• Do not use sleep to wait for a long job. A run that has to wait should be split in two: one run starts the work, and a schedule or trigger starts the next.