Hi @hello ,
Based on further research, here is what I can piece together:
1. Can the UI silently accept things that STRICT mode rejects?
Short answer: yes. The QuickSight console is more permissive than the API when it comes to validation. You can save and publish analyses in the UI that contain things like invalid calculated field expressions, broken conditional formatting, or references to columns that no longer exist in the dataset. The UI just… works around it. But when you go to publish that same asset via the API with STRICT validation, those issues surface as hard failures (INVALID_CALCULATED_COLUMN_EXPRESSION, INVALID_CONDITIONAL_FORMATTING_EXPRESSION, etc.).
So for your workflow specifically (edit in UI, publish via API with STRICT), yes, you can absolutely hit errors at publish time that the UI never told you about. I believe this is still being reported and the behavior hasn’t changed (Analysis or Dashboard Definition Validation - Q&A - Amazon Quick Community).
One thing you can do: call describe-analysis-definition and check the Errors array in the response before attempting your publish (DescribeAnalysisDefinition - Amazon Quick Sight). That’ll surface issues proactively. Alternatively, you could use LENIENT for the publish step itself to match the UI’s tolerance, but then you’d want some other mechanism to catch real problems.
2. Does LENIENT skip validation entirely / is there a performance boost?
In this docs it says “validation is skipped for specific UI errors.” That’s the full extent of what’s documented. It doesn’t elaborate on whether the underlying checks still execute (with errors suppressed) or whether those checks are bypassed entirely, so I can’t confirm either way. I also couldn’t find anything in the documentation about a performance difference between the two modes.
Hope that helps!