The Sieve playground (#97) ran every script under its own permissive defaults: a 100,000-instruction CPU limit, while allowed, large sizes. A script that breaks the server's limits for its kind passed there and then failed on delivery.
Debug now reads the live settings of the interpreter that runs the script and passes them to the playground in the link:
Account scripts (x:SieveUserScript, JMAP SieveScript) read x:SieveUserInterpreter: every limit, notification URIs, protected headers, vacation subject/prefix, and the vacation and duplicate expiries (ms → s). Extensions are all except vnd.inbuxa.while and the disabled ones, as the server builds its account runtime.
System scripts read x:SieveSystemInterpreter: CPU, variable size, redirects, outgoing messages, nested includes, Received headers, duplicate expiry and noCapabilityCheck. They also get the compiler limits the server fixes in code, and lose the mailbox actions the server switches off (fileinto, vacation, duplicate, …).
What the server sets in code rather than from settings is repeated in src/lib/sieveLimits.ts, which points to crates/common/src/config/mailstore/scripts.rs. The capability list comes from the schema's SieveCapability enum, which matches sieve-rs's Capability::all() plus the two vnd.inbuxa.* extensions.
If the settings can't be read (permissions, network), the playground opens with its defaults as before.
Checked
typecheck, lint, i18n:check, test (656; mapping tests for both interpreters plus the link), build and notice-check all pass locally.
Run against the playground's WebAssembly: with the account settings, a while script fails with Capability 'vnd.inbuxa.while' has been disabled; with a 5,000 CPU limit, a long loop stops at the limit. In both cases the implicit keep still happens, as on the server.
No new strings.
The Sieve playground (#97) ran every script under its own permissive defaults: a 100,000-instruction CPU limit, `while` allowed, large sizes. A script that breaks the server's limits for its kind passed there and then failed on delivery.
**Debug** now reads the live settings of the interpreter that runs the script and passes them to the playground in the link:
- **Account scripts** (`x:SieveUserScript`, JMAP `SieveScript`) read `x:SieveUserInterpreter`: every limit, notification URIs, protected headers, vacation subject/prefix, and the vacation and duplicate expiries (ms → s). Extensions are all except `vnd.inbuxa.while` and the disabled ones, as the server builds its account runtime.
- **System scripts** read `x:SieveSystemInterpreter`: CPU, variable size, redirects, outgoing messages, nested includes, Received headers, duplicate expiry and `noCapabilityCheck`. They also get the compiler limits the server fixes in code, and lose the mailbox actions the server switches off (fileinto, vacation, duplicate, …).
- What the server sets in code rather than from settings is repeated in `src/lib/sieveLimits.ts`, which points to `crates/common/src/config/mailstore/scripts.rs`. The capability list comes from the schema's `SieveCapability` enum, which matches sieve-rs's `Capability::all()` plus the two `vnd.inbuxa.*` extensions.
- If the settings can't be read (permissions, network), the playground opens with its defaults as before.
**Checked**
- typecheck, lint, i18n:check, test (656; mapping tests for both interpreters plus the link), build and notice-check all pass locally.
- Run against the playground's WebAssembly: with the account settings, a `while` script fails with *Capability 'vnd.inbuxa.while' has been disabled*; with a 5,000 CPU limit, a long loop stops at the limit. In both cases the implicit keep still happens, as on the server.
No new strings.
The playground ran every script under its own permissive defaults: a
100,000-instruction CPU limit, loops allowed, generous sizes. A script
that breaks the server's limits for its kind passed in the playground
and then failed on delivery.
Debug now reads the interpreter that runs the script, live:
x:SieveUserInterpreter for account scripts (x:SieveUserScript and
JMAP SieveScript) and x:SieveSystemInterpreter for system scripts, and
passes its limits, notification URIs, protected headers, vacation
defaults and expiries to the playground. The extensions follow the
server too: account scripts get every capability but vnd.inbuxa.while
and the disabled ones; system scripts lose the mailbox actions the
server switches off for them. What the server sets in code (the system
compiler's limits, the lifted Received limit for account scripts) is
repeated in sieveLimits.ts, which names where it comes from.
When the settings can't be read, the playground keeps its defaults.
No new strings.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The Sieve playground (#97) ran every script under its own permissive defaults: a 100,000-instruction CPU limit,
whileallowed, large sizes. A script that breaks the server's limits for its kind passed there and then failed on delivery.Debug now reads the live settings of the interpreter that runs the script and passes them to the playground in the link:
x:SieveUserScript, JMAPSieveScript) readx:SieveUserInterpreter: every limit, notification URIs, protected headers, vacation subject/prefix, and the vacation and duplicate expiries (ms → s). Extensions are all exceptvnd.inbuxa.whileand the disabled ones, as the server builds its account runtime.x:SieveSystemInterpreter: CPU, variable size, redirects, outgoing messages, nested includes, Received headers, duplicate expiry andnoCapabilityCheck. They also get the compiler limits the server fixes in code, and lose the mailbox actions the server switches off (fileinto, vacation, duplicate, …).src/lib/sieveLimits.ts, which points tocrates/common/src/config/mailstore/scripts.rs. The capability list comes from the schema'sSieveCapabilityenum, which matches sieve-rs'sCapability::all()plus the twovnd.inbuxa.*extensions.Checked
whilescript fails with Capability 'vnd.inbuxa.while' has been disabled; with a 5,000 CPU limit, a long loop stops at the limit. In both cases the implicit keep still happens, as on the server.No new strings.