Failure Details
Failed Jobs and Errors
| Job |
Step |
Conclusion |
| Per-Class Coverage Gate |
Enforce Per-Class Coverage Gate |
❌ failure |
| allBuildAndTestSuccessful |
Verify all jobs passed |
❌ failure (depends on above) |
The "Enforce Per-Class Coverage Gate" step failed. All build/test jobs passed successfully.
Root Cause
PR #4271 adds a new validation rule VARIABLES_NOT_ALLOWED_IN_DIRECTIVES_ON_VARIABLE_DEFINITIONS with approximately 29 new lines in OperationValidator.java (method validateVariableNotAllowedInConstantDirective at ~line 997, plus changes to checkVariable).
The test-baseline.json was last updated by merging master, so it reflects master branch coverage for OperationValidator — specifically:
graphql.validation.OperationValidator: 97.8% line, 92.2% branch, 99.0% method
However, after the PR adds new code, the actual JaCoCo report shows lower coverage because the test-baseline.json was not updated to account for the new lines/branches added by this PR. The coverage gate then detects a regression when comparing actual CI coverage against the (now stale) baseline.
Specifically, there is a branch in validateVariableNotAllowedInConstantDirective that is likely uncovered:
} else if (ancestor instanceof VariableDefinition) {
if (inDirective) {
// error – covered by test
}
return; // ← this path (inDirective=false when VariableDefinition found) may not be exercised
}
This "variable reference inside a VariableDefinition but NOT inside a Directive" path is a case where the loop terminates via the return without an error. The current test suite may not directly exercise this path (e.g., a variable reference used as a default value, though that's normally disallowed by the grammar).
Recommended Fix
Relevant file: src/main/java/graphql/validation/OperationValidator.java (method validateVariableNotAllowedInConstantDirective, ~line 997)
Generated by CI Failure Doctor
To install this workflow, run gh aw add githubnext/agentics/workflows/ci-doctor.md@ee50a3b7d1d3eb4a8c409ac9409fd61c9a66b0f5. View source at https://github.com/githubnext/agentics/tree/ee50a3b7d1d3eb4a8c409ac9409fd61c9a66b0f5/workflows/ci-doctor.md.
Failure Details
6bb68be3aa62d20adf184b3693b04798f296ae20Failed Jobs and Errors
The "Enforce Per-Class Coverage Gate" step failed. All build/test jobs passed successfully.
Root Cause
PR #4271 adds a new validation rule
VARIABLES_NOT_ALLOWED_IN_DIRECTIVES_ON_VARIABLE_DEFINITIONSwith approximately 29 new lines inOperationValidator.java(methodvalidateVariableNotAllowedInConstantDirectiveat ~line 997, plus changes tocheckVariable).The
test-baseline.jsonwas last updated by merging master, so it reflects master branch coverage forOperationValidator— specifically:graphql.validation.OperationValidator: 97.8% line, 92.2% branch, 99.0% methodHowever, after the PR adds new code, the actual JaCoCo report shows lower coverage because the
test-baseline.jsonwas not updated to account for the new lines/branches added by this PR. The coverage gate then detects a regression when comparing actual CI coverage against the (now stale) baseline.Specifically, there is a branch in
validateVariableNotAllowedInConstantDirectivethat is likely uncovered:This "variable reference inside a VariableDefinition but NOT inside a Directive" path is a case where the loop terminates via the
returnwithout an error. The current test suite may not directly exercise this path (e.g., a variable reference used as a default value, though that's normally disallowed by the grammar).Recommended Fix
test-baseline.jsonwith the actual coverage numbers produced by the PR's code (thetest-baseline.jsonin the PR only reflects master numbers, not the new code's actual coverage).validateVariableNotAllowedInConstantDirective(e.g., variable reference inside aVariableDefinitiondefault value, or in a nested object within a directive argument), then update the baseline../gradlew test jacocoTestReportand re-running the baseline update workflow to regeneratetest-baseline.json.Relevant file:
src/main/java/graphql/validation/OperationValidator.java(methodvalidateVariableNotAllowedInConstantDirective, ~line 997)