feat(analytics-engine): fix distributed COUNT(DISTINCT) / DC via HLL sketch merge + TopK optimization

[sandeshkr419]

Implements cross-shard dc() / distinct_count() using HyperLogLog sketch merge. Single-arg COUNT(DISTINCT x) is rewritten to APPROX_COUNT_DISTINCT at plan time, enabling per-shard partial HLL sketch computation with coordinator-side merge — eliminating the previous over-counting bug where per-shard distinct counts were summed.

For TopK queries (stats dc(x) by group | sort - dc(x) | head N), inserts a reduce_eval projection between the PARTIAL aggregate and the shard Sort to derive a sortable cardinality from opaque HLL state, enabling shard-side pruning that ships only top-K sketches over the wire.

Changes

Plan layer (Java)

• OpenSearchDistinctCountRule: HEP rule rewrites single-arg COUNT(DISTINCT x) → APPROX_COUNT_DISTINCT(x) before aggregate marking
• OpenSearchTopKRewriter: detects sort on engine-native-merge measures, inserts reduce_eval Project + strip Project around shard Sort
• FragmentConversionDriver: layered substrait conversion for buried PARTIAL aggregates (scan → attachPartialAggOnTop → attachFragmentOnTop per operator above); emits SETUP_PARTIAL_AGGREGATE / SETUP_FINAL_AGGREGATE instructions via tree-walk
• AggregateFunction SPI: isEngineNativeMerge(AggregateCall), reduceEvalName(), REDUCE_EVAL_OP — shared predicate and operator, no duplication across modules

Execution layer (Rust)

• force_aggregate_mode: strips Final/Partial half of aggregates; remaps ProjectionExec Column references when child schema changes after strip
• prepare_partial_plan / prepare_final_plan: activate Partial/Final execution mode on data-node/coordinator respectively
• derive_schema_from_partial_plan: extracts Partial aggregate schema for StreamingTable registration; uses substrait Root.names for authoritative column naming (no string-pattern hacking)
• reduce_eval UDF: evaluates HLL sketch state → UInt64 cardinality for TopK ranking

Test plan

• ShardBucketOversamplingIT — all TopK tests including testDcByGroup_sortDesc_head10
• TwoShardAggregationIT — all 36 reduce checks including distinct_count_by_cat
• CoordinatorReduceIT — all 21 checks including testQ10ShapeAcrossShards, testGroupByCountMultiShard
• AggregatePlanShapeTests — unit tests for rewrite + split shape
• AggregateFunctionTests — SPI enum validation

Signed-off-by: Sandesh Kumar sandeshkr419@gmail.com

[github-actions]

PR Reviewer Guide 🔍

(Review updated until commit 64b8562)

Here are some key observations to aid the review process:

🧪 PR contains tests

🔒 No security concerns identified

✅ No TODO sections

🔀 No multiple PR themes

⚡ Recommended focus areas for review Possible Issue remap_column recursively remaps column names but returns the original expression on with_new_children failure via unwrap_or(fallback). If with_new_children fails after partial remapping of children, the returned expression is inconsistent—some children remapped, some not. This can cause schema mismatches when DataFusion validates column references. The failure scenario occurs when an expression type does not support child replacement (e.g., certain custom physical expressions). fn remap_column(expr: Arc<dyn PhysicalExpr>, schema: &arrow::datatypes::SchemaRef) -> Arc<dyn PhysicalExpr> { if let Some(col) = expr.as_any().downcast_ref::<Column>() { return Arc::new(Column::new(schema.field(col.index()).name(), col.index())); } let children = expr.children(); if children.is_empty() { return expr; } let new_children: Vec<_> = children.into_iter().map(|c| remap_column(c.clone(), schema)).collect(); let fallback = expr.clone(); expr.with_new_children(new_children).unwrap_or(fallback) } Possible Issue derive_schema_from_partial_plan assumes declared_names.len() == partial_schema.fields().len() when both conditions are true, but does not verify this equality before zipping. If lengths differ (e.g., due to substrait plan inconsistencies or optimizer transformations), the zip silently truncates to the shorter length, producing a schema with fewer fields than expected. This causes downstream failures when the coordinator attempts to read all expected columns from the partial result. if let Some(partial_schema) = crate::agg_mode::partial_aggregate_schema(&physical_plan) { let has_binary = partial_schema.fields().iter().any(|f| matches!(f.data_type(), arrow::datatypes::DataType::Binary)); if has_binary && !declared_names.is_empty() && declared_names.len() == partial_schema.fields().len() { use arrow::datatypes::{Field, Schema}; Possible Issue findBuriedPartialAggregate returns null when the fragment root is itself an OpenSearchAggregate, even if that aggregate is PARTIAL and engine-native-merge. The early-return if (fragment instanceof OpenSearchAggregate) return null; at line 602 prevents detection of top-level PARTIAL aggregates that should be handled by the buried-aggregate path. This causes the layered conversion logic (lines 428-448) to skip engine-native PARTIAL aggregates at the fragment root, falling back to the standard path that does not emit SETUP_PARTIAL_AGGREGATE instructions. private static OpenSearchAggregate findBuriedPartialAggregate(RelNode fragment) { if (fragment instanceof OpenSearchAggregate) return null; Index Out of Bounds hasEngineNativeMergeMeasure computes sortIdx - groupCount to index into agg.getAggCallList() without verifying sortIdx >= groupCount. If the sort references a group-by column (sortIdx < groupCount), the subtraction yields a negative index, triggering an IndexOutOfBoundsException when accessing the aggregate call list. private static boolean hasEngineNativeMergeMeasure(OpenSearchAggregate agg, RelCollation collation) { int groupCount = agg.getGroupSet().cardinality(); for (RelFieldCollation fc : collation.getFieldCollations()) { int idx = fc.getFieldIndex(); if (idx >= groupCount && AggregateFunction.isEngineNativeMerge(agg.getAggCallList().get(idx - groupCount))) { return true; } } return false; }

[github-actions]

PR Code Suggestions ✨

Latest suggestions up to 64b8562

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Add bounds checking for aggregate list access The expression sortIdx - groupCount could produce a negative index or exceed the bounds of getAggCallList() if sortIdx is less than groupCount or if the aggregate call list is shorter than expected. Add bounds checking before accessing the list. sandbox/plugins/analytics-engine/src/main/java/org/opensearch/analytics/planner/rules/OpenSearchTopKRewriter.java [92-108] for (RelFieldCollation fc : sort.getCollation().getFieldCollations()) { int sortIdx = fc.getFieldIndex(); - if (sortIdx >= groupCount && AggregateFunction.isEngineNativeMerge(partial.getAggCallList().get(sortIdx - groupCount))) { + int aggIdx = sortIdx - groupCount; + if (sortIdx >= groupCount + && aggIdx >= 0 + && aggIdx < partial.getAggCallList().size() + && AggregateFunction.isEngineNativeMerge(partial.getAggCallList().get(aggIdx))) { ... } } Suggestion importance[1-10]: 8 __ Why: Critical bounds checking issue. The code accesses partial.getAggCallList().get(sortIdx - groupCount) without verifying that sortIdx - groupCount is within valid bounds. If sortIdx references a group key field or the list is shorter than expected, this will throw IndexOutOfBoundsException. The suggestion correctly adds necessary validation.	Medium
	Prevent infinite recursion in tree walk The recursive tree walk has no depth limit or cycle detection. If the plan contains a cycle or is extremely deep, this could cause a stack overflow. Consider adding a visited set or depth limit to prevent infinite recursion. sandbox/plugins/analytics-engine/src/main/java/org/opensearch/analytics/planner/dag/FragmentConversionDriver.java [256-266] private static boolean containsEngineNativeAggregate(RelNode root, AggregateMode mode) { + return containsEngineNativeAggregate(root, mode, new java.util.HashSet<>()); +} + +private static boolean containsEngineNativeAggregate(RelNode root, AggregateMode mode, java.util.Set<RelNode> visited) { + if (!visited.add(root)) return false; if (root instanceof OpenSearchAggregate agg && agg.getMode() == mode && agg.getAggCallList().stream().anyMatch(org.opensearch.analytics.spi.AggregateFunction::isEngineNativeMerge)) { return true; } for (RelNode child : root.getInputs()) { - if (containsEngineNativeAggregate(child, mode)) return true; + if (containsEngineNativeAggregate(child, mode, visited)) return true; } return false; } Suggestion importance[1-10]: 7 __ Why: Valid concern about potential infinite recursion in tree traversal. While Calcite's RelNode graphs are typically DAGs without cycles, adding cycle detection is a defensive programming practice that prevents stack overflow in edge cases without significant performance cost.	Medium
	Guard against empty inputs list The condition checks node.getInputs().getFirst() without verifying that node.getInputs() is non-empty. If node has no inputs, this will throw an exception. Add a guard to ensure the inputs list is not empty before accessing the first element. sandbox/plugins/analytics-engine/src/main/java/org/opensearch/analytics/planner/dag/FragmentConversionDriver.java [551-555] if (node instanceof org.apache.calcite.rel.core.Project p && isPureReorderProject(p) + && !node.getInputs().isEmpty() && containsEngineNativeAggregate(node.getInputs().getFirst(), AggregateMode.FINAL)) { return innerBytes; } Suggestion importance[1-10]: 3 __ Why: The suggestion adds a defensive check for empty inputs, but the context shows this code is within convertReduceNode which already validates single-input operators. The check node.getInputs().size() >= 2 earlier ensures non-empty inputs for this path, making the additional guard redundant but harmless.	Low

---

Previous suggestions

Suggestions up to commit 4956a4e

Category	Suggestion	Impact
Possible issue	Validate array index before access The code accesses partial.getAggCallList().get(sortIdx - groupCount) without verifying that sortIdx - groupCount is within bounds. If sortIdx is less than groupCount or the index exceeds the list size, this will throw an IndexOutOfBoundsException. sandbox/plugins/analytics-engine/src/main/java/org/opensearch/analytics/planner/rules/OpenSearchTopKRewriter.java [92-94] for (RelFieldCollation fc : sort.getCollation().getFieldCollations()) { int sortIdx = fc.getFieldIndex(); - if (sortIdx >= groupCount && AggregateFunction.isEngineNativeMerge(partial.getAggCallList().get(sortIdx - groupCount))) { + int aggIdx = sortIdx - groupCount; + if (sortIdx >= groupCount && aggIdx < partial.getAggCallList().size() + && AggregateFunction.isEngineNativeMerge(partial.getAggCallList().get(aggIdx))) { Suggestion importance[1-10]: 8 __ Why: Critical bounds check missing. The code assumes sortIdx - groupCount is valid without verifying it's within getAggCallList().size(). This could cause IndexOutOfBoundsException with malformed sort collations.	Medium
	Prevent infinite loop in tree traversal The while loop assumes walk will eventually equal partialAgg, but if the tree structure is unexpected or partialAgg is not actually an ancestor, this creates an infinite loop. Add a safety check to prevent unbounded iteration. sandbox/plugins/analytics-engine/src/main/java/org/opensearch/analytics/planner/dag/FragmentConversionDriver.java [440-445] List<RelNode> aboveAgg = new ArrayList<>(); RelNode walk = resolvedFragment; -while (walk != partialAgg) { +int maxDepth = 100; +int depth = 0; +while (walk != partialAgg && depth < maxDepth) { aboveAgg.add(walk); + if (walk.getInputs().isEmpty()) break; walk = walk.getInputs().getFirst(); + depth++; +} +if (walk != partialAgg) { + throw new IllegalStateException("Could not find partialAgg in tree"); } Suggestion importance[1-10]: 7 __ Why: Valid concern about potential infinite loops if partialAgg is not found in the tree. Adding a depth limit and explicit error handling improves robustness against malformed plans.	Medium
	Verify inputs exist before accessing The condition checks if node is a Project but doesn't verify that node.getInputs() is non-empty before calling getFirst(). If a Project node has no inputs, this will throw an exception. Add a guard to ensure inputs exist. sandbox/plugins/analytics-engine/src/main/java/org/opensearch/analytics/planner/dag/FragmentConversionDriver.java [551-555] if (node instanceof org.apache.calcite.rel.core.Project p && isPureReorderProject(p) + && !node.getInputs().isEmpty() && containsEngineNativeAggregate(node.getInputs().getFirst(), AggregateMode.FINAL)) { return innerBytes; } Suggestion importance[1-10]: 3 __ Why: The suggestion correctly identifies a potential issue, but Project nodes in Calcite always have exactly one input by design. The check is defensive but unlikely to prevent real bugs in practice.	Low
General	Handle errors explicitly in remapping Using unwrap_or with a cloned fallback silently ignores errors from with_new_children. If the operation fails for a legitimate reason (e.g., incompatible child types), the error is masked. Consider propagating the error or logging it. sandbox/plugins/analytics-backend-datafusion/rust/src/agg_mode.rs [147-150] let new_children: Vec<_> = children.into_iter().map(|c| remap_column(c.clone(), schema)).collect(); -let fallback = expr.clone(); -expr.with_new_children(new_children).unwrap_or(fallback) +match expr.with_new_children(new_children) { + Ok(new_expr) => new_expr, + Err(e) => { + log::warn!("Failed to remap column children: {}", e); + expr.clone() + } +} Suggestion importance[1-10]: 5 __ Why: The suggestion improves error visibility by logging failures instead of silently falling back. However, the current unwrap_or pattern is acceptable for non-critical remapping operations where fallback is reasonable.	Low

Suggestions up to commit f324e1e

Category	Suggestion	Impact
Possible issue	Add bounds check for list access The code accesses partial.getAggCallList().get(sortIdx - groupCount) without verifying that sortIdx - groupCount is within bounds. If sortIdx is less than groupCount or the index exceeds the aggregate call list size, this will throw IndexOutOfBoundsException. Add bounds checking before accessing the list. sandbox/plugins/analytics-engine/src/main/java/org/opensearch/analytics/planner/rules/OpenSearchTopKRewriter.java [92-94] for (RelFieldCollation fc : sort.getCollation().getFieldCollations()) { int sortIdx = fc.getFieldIndex(); - if (sortIdx >= groupCount && AggregateFunction.isEngineNativeMerge(partial.getAggCallList().get(sortIdx - groupCount))) { + int aggIdx = sortIdx - groupCount; + if (sortIdx >= groupCount + && aggIdx >= 0 + && aggIdx < partial.getAggCallList().size() + && AggregateFunction.isEngineNativeMerge(partial.getAggCallList().get(aggIdx))) { Suggestion importance[1-10]: 8 __ Why: The suggestion identifies a legitimate bounds-checking issue. The code accesses partial.getAggCallList().get(sortIdx - groupCount) without verifying the index is valid, which could cause IndexOutOfBoundsException if sortIdx - groupCount exceeds the list size.	Medium
	Check inputs exist before accessing The condition checks if node is a Project but then calls containsEngineNativeAggregate on node.getInputs().getFirst() without verifying that node has inputs. If node.getInputs() is empty, getFirst() will throw NoSuchElementException. Add a guard to ensure inputs exist before accessing them. sandbox/plugins/analytics-engine/src/main/java/org/opensearch/analytics/planner/dag/FragmentConversionDriver.java [551-555] if (node instanceof org.apache.calcite.rel.core.Project p && isPureReorderProject(p) + && !node.getInputs().isEmpty() && containsEngineNativeAggregate(node.getInputs().getFirst(), AggregateMode.FINAL)) { return innerBytes; } Suggestion importance[1-10]: 7 __ Why: The suggestion correctly identifies a potential NoSuchElementException if node.getInputs() is empty. However, the context shows this code is within convertReduceNode which processes single-input operators, making an empty inputs list unlikely but still possible.	Medium
	Validate node structure before processing The loop iterates backwards through aboveAgg but doesn't verify that each element has the expected single-input structure before calling stripSingleOperator. If any element in the list has multiple inputs or is null, stripSingleOperator may fail. Validate each node before processing to prevent runtime failures. sandbox/plugins/analytics-engine/src/main/java/org/opensearch/analytics/planner/dag/FragmentConversionDriver.java [445-448] for (int i = aboveAgg.size() - 1; i >= 0; i--) { - current = convertor.attachFragmentOnTop(stripSingleOperator(aboveAgg.get(i)), current); + RelNode node = aboveAgg.get(i); + if (node == null || node.getInputs().isEmpty()) { + throw new IllegalStateException("Invalid node in aboveAgg chain at index " + i); + } + current = convertor.attachFragmentOnTop(stripSingleOperator(node), current); } Suggestion importance[1-10]: 6 __ Why: The suggestion adds defensive validation for nodes in aboveAgg list. While the null check is reasonable, the empty inputs check may be overly strict since stripSingleOperator already handles single-input nodes and creates a placeholder child.	Low

Suggestions up to commit 6d3daf3

Category	Suggestion	Impact
Possible issue	Add bounds check for aggregate index The index calculation sortIdx - groupCount is used to access partial.getAggCallList() without bounds checking. If sortIdx is less than groupCount or if the resulting index exceeds the aggregate call list size, this will throw an IndexOutOfBoundsException. Add explicit bounds validation before the list access. sandbox/plugins/analytics-engine/src/main/java/org/opensearch/analytics/planner/rules/OpenSearchTopKRewriter.java [92-95] List<RelFieldCollation> newCollations = new ArrayList<>(); for (RelFieldCollation fc : sort.getCollation().getFieldCollations()) { int sortIdx = fc.getFieldIndex(); - if (sortIdx >= groupCount && AggregateFunction.isEngineNativeMerge(partial.getAggCallList().get(sortIdx - groupCount))) { + int aggIdx = sortIdx - groupCount; + if (sortIdx >= groupCount && aggIdx >= 0 && aggIdx < partial.getAggCallList().size() + && AggregateFunction.isEngineNativeMerge(partial.getAggCallList().get(aggIdx))) { ... } } Suggestion importance[1-10]: 8 __ Why: Critical bounds checking issue. The code accesses partial.getAggCallList().get(sortIdx - groupCount) without verifying that sortIdx - groupCount is within valid bounds. This could cause IndexOutOfBoundsException if the sort index is invalid. The suggested bounds check prevents a potential runtime crash.	Medium
	Prevent panic on out-of-bounds column index The schema.field(col.index()) call will panic if col.index() is out of bounds for the schema. This can occur if the column index from the old schema doesn't exist in the new schema after stripping. Add bounds checking and return the original expression or handle the error gracefully if the index is invalid. sandbox/plugins/analytics-backend-datafusion/rust/src/agg_mode.rs [141-145] fn remap_column(expr: Arc<dyn PhysicalExpr>, schema: &arrow::datatypes::SchemaRef) -> Arc<dyn PhysicalExpr> { if let Some(col) = expr.as_any().downcast_ref::<Column>() { - return Arc::new(Column::new(schema.field(col.index()).name(), col.index())); + if col.index() < schema.fields().len() { + return Arc::new(Column::new(schema.field(col.index()).name(), col.index())); + } + return expr; } ... } Suggestion importance[1-10]: 8 __ Why: Important safety check for Rust code. The schema.field(col.index()) call will panic if the index is out of bounds. After schema stripping operations, column indices may become invalid. The suggested bounds check prevents a panic and gracefully falls back to the original expression.	Medium
	Prevent unbounded recursion in tree walk The recursive tree walk in containsEngineNativeAggregate has no depth limit or cycle detection. If the RelNode tree contains a cycle (malformed plan) or is extremely deep, this could cause a stack overflow. Add a depth limit parameter or use an iterative approach with a visited set to prevent unbounded recursion. sandbox/plugins/analytics-engine/src/main/java/org/opensearch/analytics/planner/dag/FragmentConversionDriver.java [256-266] private static boolean containsEngineNativeAggregate(RelNode root, AggregateMode mode) { + return containsEngineNativeAggregateHelper(root, mode, new java.util.HashSet<>(), 0, 100); +} + +private static boolean containsEngineNativeAggregateHelper(RelNode root, AggregateMode mode, java.util.Set<RelNode> visited, int depth, int maxDepth) { + if (depth > maxDepth || !visited.add(root)) return false; if (root instanceof OpenSearchAggregate agg && agg.getMode() == mode && agg.getAggCallList().stream().anyMatch(org.opensearch.analytics.spi.AggregateFunction::isEngineNativeMerge)) { return true; } for (RelNode child : root.getInputs()) { - if (containsEngineNativeAggregate(child, mode)) return true; + if (containsEngineNativeAggregateHelper(child, mode, visited, depth + 1, maxDepth)) return true; } return false; } Suggestion importance[1-10]: 7 __ Why: Valid concern about potential stack overflow from unbounded recursion in containsEngineNativeAggregate. The RelNode tree structure should be acyclic by design, but adding depth protection is a reasonable defensive measure. The suggestion provides a working implementation with cycle detection and depth limiting.	Medium
	Validate factory node creation success The createPartialAggregateNode() and createFinalAggregateNode() calls are conditional on containsEngineNativeAggregate returning true, but there's no null-safety check on the factory methods. If the factory returns an empty Optional, the instruction won't be added, which could silently skip critical aggregate setup. Consider logging a warning or throwing an exception when the factory fails to create the expected node for an engine-native aggregate. sandbox/plugins/analytics-engine/src/main/java/org/opensearch/analytics/planner/dag/FragmentConversionDriver.java [246-251] if (leaf instanceof OpenSearchTableScan tableScan) { ... if (containsEngineNativeAggregate(resolvedFragment, AggregateMode.PARTIAL)) { - factory.createPartialAggregateNode().ifPresent(instructions::add); + factory.createPartialAggregateNode().ifPresentOrElse( + instructions::add, + () -> { throw new IllegalStateException("Factory failed to create PARTIAL aggregate node for engine-native merge"); } + ); } } else if (leaf instanceof OpenSearchStageInputScan && containsEngineNativeAggregate(resolvedFragment, AggregateMode.FINAL)) { - factory.createFinalAggregateNode().ifPresent(instructions::add); + factory.createFinalAggregateNode().ifPresentOrElse( + instructions::add, + () -> { throw new IllegalStateException("Factory failed to create FINAL aggregate node for engine-native merge"); } + ); } Suggestion importance[1-10]: 5 __ Why: The suggestion correctly identifies that createPartialAggregateNode() and createFinalAggregateNode() return Optional values that could be empty. However, throwing an exception may be too strict if the factory legitimately returns empty for certain backends. A warning log would be more appropriate, making this a moderate improvement rather than a critical fix.	Low

Suggestions up to commit 4acb538

Category	Suggestion	Impact
General	Handle unrecognized aggregate function gracefully The fromSqlAggFunction call can throw IllegalStateException if the aggregate function is not recognized. This exception should be caught and handled appropriately to prevent TopK rewrite failures when encountering unsupported aggregate functions. sandbox/plugins/analytics-engine/src/main/java/org/opensearch/analytics/planner/rules/OpenSearchTopKRewriter.java [94-96] if (sortIdx >= groupCount && AggregateFunction.isEngineNativeMerge(partial.getAggCallList().get(sortIdx - groupCount))) { - AggregateFunction aggFunc = AggregateFunction.fromSqlAggFunction( - partial.getAggCallList().get(sortIdx - groupCount).getAggregation()); + AggregateFunction aggFunc; + try { + aggFunc = AggregateFunction.fromSqlAggFunction( + partial.getAggCallList().get(sortIdx - groupCount).getAggregation()); + } catch (IllegalStateException e) { + continue; + } Suggestion importance[1-10]: 5 __ Why: The suggestion correctly identifies that fromSqlAggFunction can throw IllegalStateException. However, silently continuing on error may hide legitimate issues. A better approach would be to log the error or fail fast if the function is truly unsupported.	Low
	Ensure symmetric Final/FinalPartitioned matching The logic treats FinalPartitioned as equivalent to Final only when the target is Final, but doesn't handle the reverse case. If the target is FinalPartitioned and the mode is Final, they should also match to ensure symmetric handling of both final aggregate modes. sandbox/plugins/analytics-backend-datafusion/rust/src/agg_mode.rs [67-69] let agg_is_target = *agg.mode() == target - || (target == AggregateMode::Final && *agg.mode() == AggregateMode::FinalPartitioned); + || (target == AggregateMode::Final && *agg.mode() == AggregateMode::FinalPartitioned) + || (target == AggregateMode::FinalPartitioned && *agg.mode() == AggregateMode::Final); if agg_is_target { Suggestion importance[1-10]: 3 __ Why: The suggestion adds symmetric handling for Final/FinalPartitioned matching. While this could improve consistency, the PR's comment explicitly states that both modes are treated as the FINAL half when the target is Final, suggesting the asymmetry is intentional for the current use case.	Low

[github-actions]

Persistent review updated to latest commit 6d3daf3

[github-actions]

Persistent review updated to latest commit f324e1e

[github-actions]

Persistent review updated to latest commit 4956a4e

[github-actions]

Persistent review updated to latest commit 64b8562

[github-actions]

❌ Gradle check result for 64b8562: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?