DataTalksClub / DataTalksClub/website
Keep failed structured-component evidence schema-valid
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 0
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
Product outcome
A failed CI job must still publish truthful, schema-valid evidence for every selected component it actually ran. A primary quality-contract failure must remain the job/report verdict, while later structured-content evidence recording must neither inherit a false component result nor crash with a secondary validation traceback.
Observed evidence
- Push run 33295699282, quality job 99214937712 first failed in
terminology-checkbecause frozen digests differed forpodcasts.json,wiki.json, andwiki_search.json. - The evidence step then recorded
quality-evidence.json, regenerated a valid 69,982-bytecontent-invariants.json, passed the overalljob.status=failureto that component, and raisedci.evidence.EvidenceError: machine output counts are invalid. - The preserved artifact has
quality-evidence.jsonandcontent_invariants-result.json, but nocontent_invariants-evidence.json. - Current
machine_output_claimassigns the failed non-test component thecontent-invariants-v1format with only the five base zero-count fields._validate_machine_output_claimrequires that format to also carryrecordsandstructured_files, so the recorder rejects its own generated claim.
Lifecycle disposition
This is a new issue, not a reopening of #195. #195 specifically fixed failed test-log parsing and the zero-count fallback for unparseable test output; its accepted regressions remain present. This failure is a structured content-invariants-v1 claim and a multi-component job-status attribution problem. It is also distinct from #202, which covers missing or irregular artifact collection; this run retained a regular structured artifact and failed later on its count shape.
Normative authority
- Development process, especially truthful failure attribution and evidence retention.
- Risk-based verification and evidence reuse, especially component-specific normalized results/counts, digest-bound machine output, exhaustive buckets, and aggregate-report creation on failure.
- Playwright timeout contract, which states the established cross-component principle: a non-success result with no parseable counts retains digest-bound failure evidence and does not block report creation.
Scope
- Make the quality job record each selected component from that component's actual execution result, rather than copying one earlier sibling failure to work that subsequently succeeded.
- Make every non-success
content_invariantsmachine-output claim valid for the declaredcontent-invariants-v1schema, including the no-parseable-counts fallback. - Continue recording remaining selected components after one component fails, then emit the final aggregate failure report with the primary failure preserved and each component classified exactly once.
- Add focused CI-contract tests for the exact observed sequence and for a genuine failed/truncated content-invariants execution.
Non-goals
- Do not change the three frozen projection digests or the approved public headings
EventsandCommunity knowledgebase; their source/projection correction remains separate work. - Do not weaken successful structured-content proof: a success still requires the complete, positive, digest-bound invariant payload.
- Do not make any failure evidence reusable or change expiry, trust, input, environment, bucket, or verdict rules.
- No product-page, content, route, template, or visual change.
- No workflow rerun as implementation evidence until this issue has passed engineer, independent tester, and PM gates.
Acceptance criteria
- Reproduce the run-33295699282 sequence in a deterministic test: the quality component fails first; a selected content-invariants execution then succeeds; recording completes without traceback; quality is
failure, content invariants issuccesswith its realrecords/structured_filescounts and bound artifact. - A genuinely failed, cancelled, timed-out, malformed, or truncated content-invariants execution emits a schema-valid non-success envelope with format-compatible zero derived counts when no trustworthy counts exist; recording and final report creation do not raise.
- The final report preserves verdict
failure, classifies every planned component exactly once, and never converts the primary failure or any absent proof into success, reuse, or an undocumented skip. - Success-path strictness remains fail-closed: missing, malformed, empty, digest-mismatched, or incomplete
content-invariants-v1success output is rejected. - Regression coverage proves #195 remains intact for failed test logs and #202 remains intact for missing/irregular failure artifacts.
-
make test-ci,make lint,make format-check, andmake typecheckpass; the versioned verification plan/report records all component dispositions. - Screenshots are
not_applicable: this is internal CI/process behavior with no product render impact.
Dependencies
None. The test can use synthetic failure output and structured invariant artifacts; it does not depend on repairing the current projection-digest mismatch.
Related: #195, #202, #253, #261.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by locating machine_output_claim and _validate_machine_output_claim, then trace the quality-job recording flow for selected components. Build deterministic tests for the observed sibling-failure sequence and failed or truncated content-invariants output. Done means schema-valid non-success evidence, truthful per-component results, preserved primary failure, exactly-once classification, and passing make test-ci, make lint, make format-check, and make typecheck.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions, python
- Domain
- ci-cd, testing-qa
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100