Skip to content

GH-11352: Propagate a failing close() when writing files - #11353

Open
dlwldn30 wants to merge 1 commit into
spring-projects:mainfrom
Goatshave:GH-11352
Open

GH-11352: Propagate a failing close() when writing files#11353
dlwldn30 wants to merge 1 commit into
spring-projects:mainfrom
Goatshave:GH-11352

Conversation

@dlwldn30

Copy link
Copy Markdown

Fixes: #11352

cleanUpFileState() discarded every IOException, including the one raised by closing the buffered writer or stream. All three write paths call it from a finally block, and close() is where the buffer is flushed, so a full disk was reported as a successful write and the truncated temporary file was still renamed onto the result file.

cleanUpFileState() now propagates and the callers invoke it on the success path, where a failure reaches the caller. On the failure path it goes through cleanUpFileStateSuppressing(), which attaches the close error to the exception already on its way out instead of replacing it, the way try-with-resources does. clearState() still runs in both cases and the APPEND_NO_FLUSH branch is unchanged. Keeping a single finally and handing it the in-flight exception would work too and would keep the call sites shorter; happy to reshape it that way if you prefer.

Verified with ./gradlew --rerun-tasks :spring-integration-file:check: 332 tests, 0 failures, 6 skipped, checkstyle clean on main and test. FileWritingMessageHandler is referenced only from this module, so that is the whole affected surface. Reverting just the production file makes the new test fail and leaves the other 331 passing.

Contributed on behalf of Goatshave.

Fixes: spring-projects#11352

cleanUpFileState() discarded every IOException, including the one raised
by closing the buffered writer or stream. close() is where the buffer is
flushed, so a full disk was reported as a successful write and the
truncated temporary file was still promoted onto the result file.

Let cleanUpFileState() propagate, and call it on the success path where
the caller can see the failure. On the failure path the close error is
attached as a suppressed exception instead, so the exception already on
its way out is not masked. clearState() still runs either way and the
APPEND_NO_FLUSH branch is untouched.

Signed-off-by: Jiwoo Lee <dlwldn30@naver.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

FileWritingMessageHandler: a failing close() is swallowed and the truncated file is still promoted

1 participant