DataTalksClub / DataTalksClub/website

Keep failed structured-component evidence schema-valid

Open
#280 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug infra operations P0 testing
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-check because frozen digests differed for podcasts.json, wiki.json, and wiki_search.json.
  • The evidence step then recorded quality-evidence.json, regenerated a valid 69,982-byte content-invariants.json, passed the overall job.status=failure to that component, and raised ci.evidence.EvidenceError: machine output counts are invalid.
  • The preserved artifact has quality-evidence.json and content_invariants-result.json, but no content_invariants-evidence.json.
  • Current machine_output_claim assigns the failed non-test component the content-invariants-v1 format with only the five base zero-count fields. _validate_machine_output_claim requires that format to also carry records and structured_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_invariants machine-output claim valid for the declared content-invariants-v1 schema, 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 Events and Community 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 is success with its real records/structured_files counts 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-v1 success 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, and make typecheck pass; 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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.