scripted attributes and their catastrophic results

[Cantor, Scott]

> We use a bunch of scripted attributes.  If a scripted attribute fails, it prevents
> all attribute resolution / release for that principal.
> 
> Other than "don't put busted stuff in production", is there a way to make
> scripted attributes fail in a less cataclysmic way?

There's a general school of thought that it's dangerous to produce "partial" results because of the possible interdependencies (e.g. consider a script that depends on another script and is misinterpreting the absence of data from it) but the basic answer is that we need to redo all the fail fast options to get them consistently implemented in 4.0.

I see a global option on every plugin called propagateResolutionExceptions but I don't know if it's exposed in the schema or not. I don't see it in the docs.

For my own purposes I don't do this, but I would say that the only obvious workaround would be to shift any scripts from attribute definitions to data connectors (scripts for the latter didn't exist in V2). If you did that, you could add a Failover connector to the DataConnector(s) that's a dummy static source, and that suppresses any failure that happens.

That's my best suggestion unless Rod knows a better way, but he's out for a couple of weeks.

-- Scott