GH-3350: Avoid flushing data to cloud when exception is thrown by Jiayi-Wang-db · Pull Request #3351 · apache/parquet-java

Jiayi-Wang-db · 2025-10-23T12:15:54Z

Rationale for this change

Inside the InternalParquetRecordWriter::Close finally block, we call close on parquetFileWriter, which may cause incomplete data to be flushed to the cloud if an exception is thrown during the close .

What changes are included in this PR?

Remove parquetFileWriter.close out of finally block and added a unit test.

Are these changes tested?

Yes.

Are there any user-facing changes?

Users wouldn't get incomplet parquet files because of torn writes.

Closes#3350

wgtmac · 2025-10-24T01:59:32Z

This looks reasonable to me. WDYT? @gszadovszky @Fokko

gszadovszky · 2025-10-24T09:59:20Z

 this.footer = new ParquetMetadata(new FileMetaData(schema, extraMetaData, Version.FULL_VERSION), blocks);
 serializeFooter(footer, out, fileEncryptor, metadataConverter);
+ } catch (Exception e) {
+ aborted = true;


We do not want to swallow the exception, just set the flag and re-throw.

We should probably do the same pattern for every public method that may throw an exception.

I’m not familiar with the direct buffer change, but in InternalParquetRecordWriter, there’s only one place where aborted is marked. Is that the only place that could cause an aborted write? If so, we don’t need to apply the same pattern to every public method in ParquetFileWriter.

It does look that way. The write function in InternalParquetRecordWriter is the only public function that can throw an exception (except close). So after we mark it as aborted there and abort the file write in the close call, we should cover all cases.

gszadovszky · 2025-10-24T10:01:12Z

+ AutoCloseables.uncheckedClose(parquetFileWriter);
 } finally {
- AutoCloseables.uncheckedClose(columnStore, pageStore, bloomFilterWriteStore, parquetFileWriter);
+ AutoCloseables.uncheckedClose(columnStore, pageStore, bloomFilterWriteStore);


Now that we have ParquetFileWriter to handle the "aborted" state, this change can be reverted.

Yes, I haven't finish my change.

Sorry, then. I was too fast. 😄
Ping me when you're ready.

Thanks for the quick review!

gszadovszky

I’m not familiar with the direct buffer change, but in InternalParquetRecordWriter, there’s only one place where aborted is marked. Is that the only place that could cause an aborted write? If so, we don’t need to apply the same pattern to every public method in ParquetFileWriter.

This is true for your workflow where ParquetFileWriter is only used via InternalParquetRecordWriter. But the latter one is a public class and used directly in other workflows. For a more complete fix it would be nicer to handle this case as well.

Jiayi-Wang-db · 2025-10-30T17:32:29Z

For a more complete fix it would be nicer to handle this case as well.

It ends up a bit messy and ugly. Let me know if you have better advice to cover all the cases. @gszadovszky

gszadovszky

You also have some code format issues.

I don't think your solution is ugly. I think you've made the best out of it. @wgtmac, do you have a better idea?

Meanwhile, this change only prevents additional writes after an exception happens. If we write e.g. multiple row groups and no I/O issue happens during the flushing of the first one, we would still have garbage on the target if the writing of the second row group fails, right? (We practically cannot prevent that because we don't want to keep the whole file in memory.)

gszadovszky · 2025-10-31T05:12:34Z

+ @FunctionalInterface
+ interface IOCallable<T> {
+ T call() throws IOException;
+ }
+
+ private <T> T withAbortOnFailure(IOCallable<T> action) throws IOException {
+ try {
+ return action.call();
+ } catch (IOException e) {
+ aborted = true;
+ throw e;
+ }
+ }
+
+ @FunctionalInterface
+ interface IORunnable {
+ void run() throws IOException;
+ }
+
+ private void withAbortOnFailure(IORunnable action) throws IOException {
+ try {
+ action.run();
+ } catch (IOException e) {
+ aborted = true;
+ throw e;
+ }
+ }
+


Maybe, you could move these to a specific utility. At least the functional interfaces. But, with an additional "abort action" in the parameter, even the withAbort functions as well.

Can we leave them as they are to make it simple. And maybe extract them later if we want to use the same pattern in other files?I

Sure, that makes sense

Jiayi-Wang-db · 2025-10-31T13:39:10Z

If we write e.g. multiple row groups and no I/O issue happens during the flushing of the first one, we would still have garbage on the target if the writing of the second row group fails, right? (We practically cannot prevent that because we don't want to keep the whole file in memory.)

@gszadovszky Digging into this further, I think the statement is not correct.
The function you mentioned, InternalParquetRecordWriter::flushRowGroupToStore, is called when the in-memory records are about to exceed the limit. However, the data is written into the stream, but flush/close is not called, so the data is not visible to other readers. Only the final close() call in ParquetFileWriter triggers a FSOutputFileStream close, which finalizes the file. Therefore, our fix addresses all of the potential incomplete parquet files.

gszadovszky · 2025-10-31T13:47:08Z

If we write e.g. multiple row groups and no I/O issue happens during the flushing of the first one, we would still have garbage on the target if the writing of the second row group fails, right? (We practically cannot prevent that because we don't want to keep the whole file in memory.)
@gszadovszky Digging into this further, I think the statement is not correct. The function you mentioned, InternalParquetRecordWriter::flushRowGroupToStore, is called when the in-memory records are about to exceed the limit. However, the data is written into the stream, but flush/close is not called, so the data is not visible to other readers. Only the final close() call in ParquetFileWriter triggers a FSOutputFileStream close, which finalizes the file. Therefore, our fix addresses all of the potential incomplete parquet files.

Thanks for the clarification, @Jiayi-Wang-db. It makes sense. I'll approve this but will wait for next week for other potential feedback.

Jiayi-Wang-db · 2025-11-10T09:57:22Z

Hi @gszadovszky , another ask regarding this change. Do you think it is necessary to backport this change to earlier versions?

gszadovszky · 2025-11-10T10:18:49Z

@Jiayi-Wang-db, since it is a bug, it makes sense to backport the fix to the last two release branches: parquet-1.16.x and parquet-1.15.x. I do not feel the urgency though, to actually make releases only for this one. But it'll be included when we make them.

(cherry picked from commit 2bcd2bd)

gszadovszky · 2025-11-10T10:39:49Z

Backported to parquet-1.16.x

gszadovszky · 2025-11-10T10:47:39Z

@Jiayi-Wang-db, would you like to contribute the 1.15.x backport? It has a couple of conflicts. Just put up a PR and I'll review/approve.

Jiayi-Wang-db · 2025-11-10T16:43:16Z

@Jiayi-Wang-db, would you like to contribute the 1.15.x backport? It has a couple of conflicts. Just put up a PR and I'll review/approve.

Sure. I will put up a pr.

…pache#3351)

#3355)

Jiayi-Wang-db added 2 commits October 23, 2025 14:05

Avoid flushing data to cloud when exception is thrown.
a51bcae

Added unit test
52a7a41

gszadovszky requested changes Oct 24, 2025
View reviewed changes

Comment threadparquet-hadoop/src/main/java/org/apache/parquet/hadoop/InternalParquetRecordWriter.java Outdated

Update ParquetFileWriter.java
d4b1efa

gszadovszky requested changes Oct 24, 2025
View reviewed changes

Jiayi-Wang-db added 2 commits October 24, 2025 12:33

fix
f233318

lint
897f96a

Jiayi-Wang-db requested a review from gszadovszky October 24, 2025 10:46

gszadovszky requested changes Oct 24, 2025
View reviewed changes

Comment threadparquet-hadoop/src/main/java/org/apache/parquet/hadoop/ParquetFileWriter.java Outdated
Comment threadparquet-hadoop/src/main/java/org/apache/parquet/hadoop/ParquetFileWriter.java Outdated

fix more public functions
3a8e343

Jiayi-Wang-db requested a review from gszadovszky October 30, 2025 17:32

gszadovszky requested changes Oct 31, 2025
View reviewed changes

spotless
fa193d8

Jiayi-Wang-db requested a review from gszadovszky October 31, 2025 13:39

gszadovszky approved these changes Oct 31, 2025
View reviewed changes

gszadovszky merged commit 2bcd2bd into apache:masterNov 3, 2025
7 checks passed

gszadovszky pushed a commit that referenced this pull request Nov 10, 2025
GH-3350: Avoid flushing data to cloud when exception is thrown (#3351)
3347f6d
(cherry picked from commit 2bcd2bd)

Jiayi-Wang-db added a commit to Jiayi-Wang-db/parquet-java that referenced this pull request Nov 10, 2025
apacheGH-3350: Avoid flushing data to cloud when exception is thrown (a…
0353876
…pache#3351)

Jiayi-Wang-db added a commit to Jiayi-Wang-db/parquet-java that referenced this pull request Nov 10, 2025
apacheGH-3350: Avoid flushing data to cloud when exception is thrown (a…
764b656
…pache#3351)

Jiayi-Wang-db added a commit to Jiayi-Wang-db/parquet-java that referenced this pull request Nov 10, 2025
apacheGH-3350: Avoid flushing data to cloud when exception is thrown (a…
bf36058
…pache#3351)

Jiayi-Wang-db mentioned this pull request Nov 10, 2025
GH-3350: Avoid flushing data to cloud when exception is thrown (#3351) #3355
Merged

wgtmac pushed a commit that referenced this pull request Jan 23, 2026
GH-3350: Avoid flushing data to cloud when exception is thrown (#3351) (
7897da4
#3355)

Uh oh!

Conversation

Jiayi-Wang-db commented Oct 23, 2025

Rationale for this change

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

Uh oh!

wgtmac commented Oct 24, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Jiayi-Wang-dbOct 24, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gszadovszky left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Jiayi-Wang-db commented Oct 30, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gszadovszky left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Jiayi-Wang-db commented Oct 31, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gszadovszky commented Oct 31, 2025

Uh oh!

Uh oh!

Jiayi-Wang-db commented Nov 10, 2025

Uh oh!

gszadovszky commented Nov 10, 2025

Uh oh!

gszadovszky commented Nov 10, 2025

Uh oh!

gszadovszky commented Nov 10, 2025

Uh oh!

Jiayi-Wang-db commented Nov 10, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Jiayi-Wang-dbOct 24, 2025•
edited
Loading

Jiayi-Wang-db commented Oct 30, 2025•
edited
Loading

Jiayi-Wang-db commented Oct 31, 2025•
edited
Loading