Problem
Protected develop@942d164ceb7af497bb28a95f842db96429d1bdc4 documents EtlJobSnapshot.failureCode as a stable terminal failure code that is null before failure, but the public value-object constructor currently accepts contradictory combinations such as PENDING/RUNNING/SUCCEEDED with a non-null failure code and FAILED with no usable failure code. EtlJobStatusResponse repeats the same externally visible semantic contract.
That allows an internally inconsistent durable-job state to cross the operator/client status boundary instead of failing at construction, weakening status integrity and making downstream interpretation ambiguous.
Acceptance
Use strict RED -> GREEN. At the real public model boundary, prove that:
- non-
FAILED snapshots/responses reject a non-null failure code;
FAILED snapshots/responses require a non-blank stable failure code;- current valid pending/running/succeeded and failed representations remain constructible;
- existing null-required and non-negative attempt-count invariants remain unchanged;
- public Javadocs state the lifecycle-dependent invariant clearly.
Keep this bounded to the durable-job model/status representation unless fresh evidence requires a smaller supporting change. Do not touch the active stack root #121, canonical docs PR #149, shared POM/workflow gates, or another active writer lane.
Problem
Protected
develop@942d164ceb7af497bb28a95f842db96429d1bdc4documentsEtlJobSnapshot.failureCodeas a stable terminal failure code that isnullbefore failure, but the public value-object constructor currently accepts contradictory combinations such asPENDING/RUNNING/SUCCEEDEDwith a non-null failure code andFAILEDwith no usable failure code.EtlJobStatusResponserepeats the same externally visible semantic contract.That allows an internally inconsistent durable-job state to cross the operator/client status boundary instead of failing at construction, weakening status integrity and making downstream interpretation ambiguous.
Acceptance
Use strict RED -> GREEN. At the real public model boundary, prove that:
FAILEDsnapshots/responses reject a non-null failure code;FAILEDsnapshots/responses require a non-blank stable failure code;Keep this bounded to the durable-job model/status representation unless fresh evidence requires a smaller supporting change. Do not touch the active stack root #121, canonical docs PR #149, shared POM/workflow gates, or another active writer lane.