@david_chisnall yeah the Cloudflare incident looks like result of them not doing a thorough audit for SPOFs. preventing or mitigating each of the "what if" cases possible. layered defense is wise

@david_chisnall part of the problem is also that exceptions aren't tracked at the type system level. IIUC the Cloudflare parser correctly returned an error, which got converted into an exception by `unwrap`. Sandboxing would have to be applied to the correct place, otherwise it'd be the same problem: sandbox detects an unexpected error, which causes the application to crash with an unhandled exception (you can try to force the caller to handle it by using a Result type, but they can just convert it back into an exception if they're not careful).
Built-in support for A/B deployments would be great though, whether at the language or the sandbox level. IIUc the reason why sandboxing would help here is that it'd make it trivial to choose a different "image" to run for the parser, whereas in a regular application you couldn't do that due to symbol conflicts (unless you unload and reload a DSO, but not everything supports that).
Although systems like kubernetes do have support for rolling out and back services, health checks, etc..
Automated rollbacks are still tricky to get right if you have any state, because the old code may not be able to deal e.g. with a new DB schema, and then you have to roll that back too. And the rollback code could be buggy, since it is exercised less frequently.