We need to have a clearer discussion of FATAL vs ERROR.
FATAL was agreed to have clear semantics:
- Guaranteed to fail your deployment
- Cannot be suppressed (no point in that, because it's guaranteed to fail your deployment)
I'm seeing a lot of rules currently marked as FATAL that currently do some service-specific content filtering, like "oh this value is too high or too low or doesn't match a regex". Those are all subject to data pollution (service can advertise the constraints incorrectly) or change (service may stretch the boundaries in the future).
If that happens, our users will be stuck with an error that is incorrect, but also one that is insuppressible by the rules that we set for FATAL.
We should probably only use FATAL for "malformed CloudFormation template"-level errors, where we are 100% certain that this won't execute correctly. This is AWS, which means that any rule you think you can divine will be broken by some team somewhere. Any guess is apt to be wrong, and we can't subject our users to those.
We need to have a clearer discussion of FATAL vs ERROR.
FATAL was agreed to have clear semantics:
I'm seeing a lot of rules currently marked as FATAL that currently do some service-specific content filtering, like "oh this value is too high or too low or doesn't match a regex". Those are all subject to data pollution (service can advertise the constraints incorrectly) or change (service may stretch the boundaries in the future).
If that happens, our users will be stuck with an error that is incorrect, but also one that is insuppressible by the rules that we set for FATAL.
We should probably only use FATAL for "malformed CloudFormation template"-level errors, where we are 100% certain that this won't execute correctly. This is AWS, which means that any rule you think you can divine will be broken by some team somewhere. Any guess is apt to be wrong, and we can't subject our users to those.