scripting

Limites du sandbox

Budgets CPU et mémoire, ce que la VM bytecode interdit, et comment opter pour des fenêtres plus longues.

Chaque script tourne dans une VM bytecode avec des budgets durs CPU et mémoire, appliqués par évaluation. Une boucle infinie ne fait pas tomber l'app.

Screener sous le sandbox — 200 ms par symbole, le fan-out reste instantané.

Budgets par défaut

| Surface | CPU par barre | Plafond mémoire | |---|---|---| | Indicator (aperçu graphique) | 50 ms | 16 Mo | | Alert (par évaluation) | 50 ms | 16 Mo | | Screener (par symbole) | 200 ms | 32 Mo | | Drawing | 50 ms | 16 Mo | | Strategy (par barre) | 100 ms | 32 Mo | | Backtester (run complet) | 60 s | 256 Mo | | Worker VPS (par évaluation) | 200 ms | 64 Mo |

Si un budget est dépassé, la VM tue l'évaluation et signale une erreur de violation du sandbox dans l'éditeur. Les évaluations suivantes continuent.

Capacités interdites

La VM n'accède pas à :

Le système de fichiers hôte.
Des sockets réseau arbitraires. Seules les built-ins auditées (p. ex. notify sur une liste de webhooks connue) atteignent le réseau.
Du code natif. Pas de FFI.
L'horloge hôte — les scripts lisent les timestamps de barres via bar(N), pas Date.now().
L'état d'autres scripts. Chaque script est isolé.

Annulation

Un script peut être annulé en cours d'évaluation :

L'utilisateur ferme le graphique, édite le script, ou frappe le kill switch.
Le budget CPU expire.
Pour le cloud worker : un plafond de perte journalière ou une pause admin tire.

L'annulation est coopérative — la VM injecte des checkpoints entre les opérations bytecode, donc une boucle infinie serrée se termine en ~1 ms du signal d'annulation.

Opter pour des budgets plus longs

Les comptes Pro peuvent demander des budgets étendus pour des scripts spécifiques via métadonnées dans le fichier :

// budget: cpu=500ms mem=128mb

L'approbation est révisée automatiquement — l'abus dégrade la requête.