Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

PropertiesPersistingMetadataStore does not retry flush after an IOException

Closed Beginner friendly
  • Is something wrong?
#11,495 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
78/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
java
Domain
backend

Research direction

Start by locating PropertiesPersistingMetadataStore and reading its flush() implementation, then reproduce the failure with the temporary-directory sequence in the issue. Add or adapt a regression test showing that a failed write can be retried after the directory is restored, while successful writes retain their current behavior.

Written by the indexing model from the issue text.

Description

In what version(s) of Spring Integration are you seeing this issue?

Current main, 7.2.0-SNAPSHOT at 2271d40b75b127dd575e680dc9081cb4eb76ce3f, on macOS arm64 with JDK 25.

Describe the bug

PropertiesPersistingMetadataStore clears its dirty flag before attempting to persist metadata. If writing fails with an IOException, the flag stays false. Once the filesystem becomes available again, a subsequent flush() skips the write unless another mutation has marked the store dirty.

As a result, an application cannot persist its pending processing checkpoint simply by retrying flush() after a transient write failure. Reloading the store can lose that checkpoint and lead to duplicate processing.

To Reproduce

  1. Initialize a store in a temporary directory and put a checkpoint.
  2. Remove its empty metadata file and directory to simulate an unavailable output path.
  3. Call flush(); it logs the write failure.
  4. Recreate the directory and call flush() again, without another mutation.
  5. Open a fresh store at the same path. The checkpoint is missing.

Expected behavior

A failed write should leave the store dirty so that a later flush() can retry it.

Sample

The following uses only temporary filesystem state. Imports: java.nio.file.Files and org.springframework.integration.metadata.PropertiesPersistingMetadataStore.

var directory = Files.createTempDirectory("metadata-retry-");
var store = new PropertiesPersistingMetadataStore();
store.setBaseDirectory(directory.toString());
store.afterPropertiesSet();
store.put("lastProcessedId", "42");

Files.delete(directory.resolve("metadata-store.properties"));
Files.delete(directory);
store.flush(); // Logs the expected FileNotFoundException.

Files.createDirectory(directory);
store.flush();

var restored = new PropertiesPersistingMetadataStore();
restored.setBaseDirectory(directory.toString());
restored.afterPropertiesSet();
System.out.println(restored.get("lastProcessedId")); // null; expected "42".

I have a regression test that fails on the unmodified source and passes after restoring dirty = true in the IOException handler. This keeps the existing successful-write behavior.

AI disclosure: I used Codex to investigate this issue, implement the proposed fix and regression test, run local checks, and draft this report.

Dominant language
Java
Stars
1.6k
Forks
1.2k
Avg merge
10h 56m
Merged PRs (30d)
70

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from spring-projects/spring-integration

All issues in spring-projects/spring-integration

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.