Loadingone moment…
Sign in to run and submit your work
Reading is open to everyone. Running code and saving drafts need an account so your work is yours and comes back on your next visit.
or
CODE WORKSPACE
Every run leaves a receipt: how many rows it read, how many it wrote, how many it rejected, and whether anybody should be woken up. The receipt is only worth having if the numbers add up.
Write build_run_manifest(counts, thresholds). It returns the manifest, including the rows that are unaccounted for and a status derived from the thresholds.
Function to write
build_run_manifest(counts: dict, thresholds: dict) -> dictA manifest dict with the counts, the unaccounted rows, the reject rate and a status.
How to approach it
Work out what the starter says about a run that lost seven rows.
Sample cases
+ 2 held back until you submit
a balanced run over the warning line
Everything is accounted for and the reject rate is above warn but below fail.
Input
Argument 1
{
'rows_in': 100,
'written': 97,
'rejected': 3
}Argument 2
{
'warn_above': 0.01,
'fail_above': 0.05
}Returns
{
'rows_in': 100,
'written': 97,
'rejected': 3,
'unaccounted': 0,
'reject_rate': 0.03,
'status': 'warning'
}rows that went nowhere
Seven rows are neither written nor rejected, which outranks any reject-rate verdict.
Input
Argument 1
{
'rows_in': 100,
'written': 90,
'rejected': 3
}Argument 2
{
'warn_above': 0.01,
'fail_above': 0.05
}Returns
{
'rows_in': 100,
'written': 90,
'rejected': 3,
'unaccounted': 7,
'reject_rate': 0.03,
'status': 'unbalanced'
}an empty run
No rows in is a valid run, not a division by zero and not a failure.
Input
Argument 1
{}Argument 2
{
'warn_above': 0.01,
'fail_above': 0.05
}Returns
{
'rows_in': 0,
'written': 0,
'rejected': 0,
'unaccounted': 0,
'reject_rate': 0,
'status': 'ok'
}Constraints
rows_in, written, rejected, unaccounted, reject_rate and status. A missing count is 0.unaccounted is rows_in - (written + rejected). It should be zero, and the manifest exists to say when it is not.reject_rate is rejected / rows_in, rounded to 4 places, and 0.0 when nothing came in.unbalanced whenever rows went missing — that outranks any rate verdict, because a run that lost rows is a different problem.failed above fail_above, warning above warn_above, else ok. Both comparisons are strictly greater.ok, not a division by zero.Worked example
With rows_in 100, written 90 and rejected 3, seven rows are unaccounted for. The reject rate is 0.03, which is above the warning line — but the status is unbalanced, not warning.
That ordering is the point. A rate says the data was worse than usual; a gap says the job lost rows and nobody knows where they went, and reporting the second as the first is how a silent data-loss bug survives a week of green dashboards.
What this tests
That a manifest is evidence rather than decoration: the counts have to reconcile, the division has to be guarded, and the severity ordering has to reflect which failure is worse rather than which check happened to run first.
build_run_manifest(counts: dict, thresholds: dict) -> dictSubmit for review to find out what your query gets right, what it gets wrong, and how it compares with the best working query for this exercise.
This scenario runs a full workspace — editor, canvas and results side by side. It needs a laptop or desktop to be usable. Open this page on a bigger screen to start building.