This is an automated email from the ASF dual-hosted git repository.

HyukjinKwon pushed a commit to branch branch-4.2
in repository https://gitbox.apache.org/repos/asf/spark.git


The following commit(s) were added to refs/heads/branch-4.2 by this push:
     new a45dd16c8536 [SPARK-57961][SQL][TEST][FOLLOWUP] Fix scalastyle line 
length violations in MetricsFailureInjectionSuite
a45dd16c8536 is described below

commit a45dd16c85361fb2f13675ce51ac9666cd57e25b
Author: Hyukjin Kwon <[email protected]>
AuthorDate: Mon Jul 6 19:57:14 2026 +0900

    [SPARK-57961][SQL][TEST][FOLLOWUP] Fix scalastyle line length violations in 
MetricsFailureInjectionSuite
    
    ### What changes were proposed in this pull request?
    
    This is a follow-up of #57037 (SPARK-57959). That PR added an explanatory 
comment block to `MetricsFailureInjectionSuite`, and four of those comment 
lines exceed the 100-character limit, breaking the `scalastyle` check on 
`master`:
    
    ```
    [error] .../MetricsFailureInjectionSuite.scala:348: File line length 
exceeds 100 characters
    [error] .../MetricsFailureInjectionSuite.scala:349: File line length 
exceeds 100 characters
    [error] .../MetricsFailureInjectionSuite.scala:352: File line length 
exceeds 100 characters
    [error] .../MetricsFailureInjectionSuite.scala:353: File line length 
exceeds 100 characters
    ```
    
    This PR reflows the comment block so every line fits within 100 characters. 
No code or test logic is changed.
    
    ### Why are the changes needed?
    
    To fix the broken `scalastyle` check on `master` (and 
`branch-4.x`/`branch-4.2`, where the offending commit was also backported).
    
    ### Does this PR introduce _any_ user-facing change?
    
    No.
    
    ### How was this patch tested?
    
    ```
    grep -nP '.{101,}' 
sql/core/src/test/scala/org/apache/spark/sql/execution/metric/MetricsFailureInjectionSuite.scala
    ```
    
    returns no matches. The change is comments-only.
    
    ### Was this patch authored or co-authored using generative AI tooling?
    
    Generated-by: Claude Code (Opus 4.8)
    
    Closes #57039 from HyukjinKwon/fix/spark-57959-scalastyle-lines.
    
    Authored-by: Hyukjin Kwon <[email protected]>
    Signed-off-by: Hyukjin Kwon <[email protected]>
    (cherry picked from commit 4995e6f68c424de361371ecfa6fa0cd87c83617f)
    Signed-off-by: Hyukjin Kwon <[email protected]>
---
 .../execution/metric/MetricsFailureInjectionSuite.scala | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git 
a/sql/core/src/test/scala/org/apache/spark/sql/execution/metric/MetricsFailureInjectionSuite.scala
 
b/sql/core/src/test/scala/org/apache/spark/sql/execution/metric/MetricsFailureInjectionSuite.scala
index e3f2e7ca2f08..2ae2ea6339fe 100644
--- 
a/sql/core/src/test/scala/org/apache/spark/sql/execution/metric/MetricsFailureInjectionSuite.scala
+++ 
b/sql/core/src/test/scala/org/apache/spark/sql/execution/metric/MetricsFailureInjectionSuite.scala
@@ -342,14 +342,15 @@ class MetricsFailureInjectionSuite
             finalDf
           }
 
-          // The INJECT_SHUFFLE_FETCH_FAILURES machinery corrupts mapper-0 of 
the first successful
-          // attempt of the shuffle map stage. Whether the downstream reducer 
observes the resulting
-          // FetchFailed (and thus forces the stage-1 recompute that inflates 
the raw metric) depends
-          // on task scheduling within the shared SparkContext; across the 
suite it occasionally does
-          // not fire, leaving stage1Metric at exactly 300 and failing "value 
> 300" (a ~1/6 flake,
-          // more frequent on slower runners such as macOS arm64). When we 
require a recompute
-          // (injectFailure = true), re-run the query until the injection 
actually fires. Each attempt
-          // resets the metrics, so a successful attempt is indistinguishable 
from a first-try success.
+          // The INJECT_SHUFFLE_FETCH_FAILURES machinery corrupts mapper-0 of 
the first
+          // successful attempt of the shuffle map stage. Whether the 
downstream reducer observes
+          // the resulting FetchFailed (and thus forces the stage-1 recompute 
that inflates the raw
+          // metric) depends on task scheduling within the shared 
SparkContext; across the suite it
+          // occasionally does not fire, leaving stage1Metric at exactly 300 
and failing
+          // "value > 300" (a ~1/6 flake, more frequent on slower runners such 
as macOS arm64).
+          // When we require a recompute (injectFailure = true), re-run the 
query until the
+          // injection actually fires. Each attempt resets the metrics, so a 
successful attempt is
+          // indistinguishable from a first-try success.
           var finalDf = runOnce()
           if (injectFailure) {
             var attempts = 1


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to