Aborting a build while artifacts are being copied through the remoting channel results in a FAILED status instead of an ABORTED status.
After discussing this with jglick, he provided me hints on how to fix that, I quote him:
FastPipedInputStream.read could be made to throw InterruptedIOException rather than a generic IOException. Then FilePath.readFromTar could rethrow either InterruptedIOException or another InterruptedException as an InterruptedException with details about the tar entry (the signatures of its callers allow InterruptedException). Proving this all works in a test could be tricky, since you would need to have a special remoting channel that deliberately hangs at a specific point (the code in the mock-slave plugin could perhaps be ported to a test utility).
Stack trace on build log:
java.io.IOException: java.io.IOException: Failed to extract /..... of 193 files at hudson.FilePath.readFromTar(FilePath.java:2286) at hudson.FilePath.copyRecursiveTo(FilePath.java:2197) at jenkins.model.StandardArtifactManager.archive(StandardArtifactManager.java:61) at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:218) ... Caused by: java.io.IOException: java.lang.InterruptedException at hudson.remoting.FastPipedInputStream.read(FastPipedInputStream.java:177) at hudson.util.HeadBufferingStream.read(HeadBufferingStream.java:61) ... Caused by: java.util.concurrent.ExecutionException: java.io.IOException: Pipe is already closed at hudson.remoting.Channel$3.adapt(Channel.java:784) at hudson.remoting.Channel$3.adapt(Channel.java:779)
- is related to
-
JENKINS-16629 Unkillable build in ArtifactArchiver → FastPipedInputStream.read
-
- Open
-
- links to
[JENKINS-30713] FAILED status reported for interrupted build
Component/s | New: core [ 15593 ] | |
Component/s | Original: copy-to-slave-plugin [ 15691 ] |
Description |
Original:
Aborting a build while artifacts are being copied through the remoting channel results in a FAILED status instead of an ABORTED status. After discussing this with [~jglick], he provided me hints on how to fix that, I quote him: ??{{FastPipedInputStream.read}} could be made to throw {{InterruptedIOException}} rather than a generic IOException. Then FilePath.readFromTar could rethrow either {{InterruptedIOException}} or another {{InterruptedException}} as an {{InterruptedException}} with details about the tar entry (the signatures of its callers allow {{InterruptedException}}). Proving this all works in a test could be tricky, since you would need to have a special remoting channel that deliberately hangs at a specific point (the code in the mock-slave plugin could perhaps be ported to a test utility).?? Stack trace on build log: {code} java.io.IOException: java.io.IOException: Failed to extract /..... of 193 files at hudson.FilePath.readFromTar(FilePath.java:2286) at hudson.FilePath.copyRecursiveTo(FilePath.java:2197) at jenkins.model.StandardArtifactManager.archive(StandardArtifactManager.java:61) at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:218) ... Caused by: java.io.IOException: java.lang.InterruptedException at hudson.remoting.FastPipedInputStream.read(FastPipedInputStream.java:177) at hudson.util.HeadBufferingStream.read(HeadBufferingStream.java:61) ... Caused by: java.util.concurrent.ExecutionException: java.io.IOException: Pipe is already closed at hudson.remoting.Channel$3.adapt(Channel.java:784) at hudson.remoting.Channel$3.adapt(Channel.java:779) {code} |
New:
Aborting a build while artifacts are being copied through the remoting channel results in a FAILED status instead of an ABORTED status. After discussing this with [~jglick], he provided me hints on how to fix that, I quote him: bq. {{FastPipedInputStream.read}} could be made to throw {{InterruptedIOException}} rather than a generic {{IOException}}. Then {{FilePath.readFromTar}} could rethrow either {{InterruptedIOException}} or another {{InterruptedException}} as an {{InterruptedException}} with details about the tar entry (the signatures of its callers allow {{InterruptedException}}). Proving this all works in a test could be tricky, since you would need to have a special remoting channel that deliberately hangs at a specific point (the code in the mock-slave plugin could perhaps be ported to a test utility). Stack trace on build log: {code} java.io.IOException: java.io.IOException: Failed to extract /..... of 193 files at hudson.FilePath.readFromTar(FilePath.java:2286) at hudson.FilePath.copyRecursiveTo(FilePath.java:2197) at jenkins.model.StandardArtifactManager.archive(StandardArtifactManager.java:61) at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:218) ... Caused by: java.io.IOException: java.lang.InterruptedException at hudson.remoting.FastPipedInputStream.read(FastPipedInputStream.java:177) at hudson.util.HeadBufferingStream.read(HeadBufferingStream.java:61) ... Caused by: java.util.concurrent.ExecutionException: java.io.IOException: Pipe is already closed at hudson.remoting.Channel$3.adapt(Channel.java:784) at hudson.remoting.Channel$3.adapt(Channel.java:779) {code} |
Labels | New: remoting |
Link | New: This issue is related to JENKINS-16629 [ JENKINS-16629 ] |
Workflow | Original: JNJira [ 165837 ] | New: JNJira + In-Review [ 182164 ] |
Remote Link | New: This issue links to "CloudBees Internal OSS-274 (Web Link)" [ 18924 ] |