Name the check fields qualityId and failedSamples

[jochenchrist]

The test-results model spells every other field in camelCase (runId, dataContractId, timestampStart), so the two Check fields that carried the Python attribute name now do too: quality_id -> qualityId, failed_samples -> failedSamples.

Backward compatibility

The old names stay available in every direction, so nothing that reads or writes them breaks:

usage	behavior
check.failed_samples (read)	returns failedSamples, DeprecationWarning
check.failed_samples = rows (write)	sets failedSamples, DeprecationWarning
Check(quality_id="r")	populates qualityId
Check.model_validate({"quality_id": "r"})	populates qualityId
serialization	writes both names when the field is set

The write path needs the property setter specifically: without it pydantic rejects assignment to an unknown attribute, and check.failed_samples = samples was the common usage.

Serialization writes both spellings so a consumer of /api/test-results keeps working:

{
  "qualityId": "orders_not_empty",
  "failedSamples": [{"id": 1}],
  "quality_id": "orders_not_empty",
  "failed_samples": [{"id": 1}]
}

Only set values are duplicated, so an unset field stays absent under the old name even in a full dump that keeps nulls, and a run with no quality rules grows by nothing. Serializing reads the field rather than the deprecated property, so publishing a run emits no DeprecationWarning.

Tests

tests/test_run_check_deprecated_fields.py covers each row of the table plus the unset case. The suite was also run with -W error::DeprecationWarning: no code path inside the CLI uses the old names.

🤖 Generated with Claude Code