Checks help to make sure that the flow’s pipeline is behaving like expected. They also accelerate the development process by:
early-stopping a job
pinpointing which table did not pass a check (e.g. « Checks on the outputs produced 1 errors »).
However, I noticed that these two features do not always work when implementing a check at the entire dataset level (not at the partition level) of a partitioned table. In particular:
a failing check does not stop during the recursive build job, the error is only raised at the end of the entire job (thus, if it is time-consuming, the user can wait a long time before being notified of a problem)
the message is not explicit. In particular, the message does not point out which table failed to pass the check and the error type.
Here is an illustration of this issue:
The check that fails on a partitioned table (note that the checks is computed at each build) :
The check behaviour when re-building that partitioned table in a recursive build :