sorry sagar, I asked Codex and it seems the Ser/De customization is unavoidable:

The PR description already claims this behavior, but the current implementation does not provide it: `prevFilePaths` is a `transient Lazy`, and the round-trip test explicitly expects the paths to disappear.

Use two fields:

- A normal serializable field containing the resolved map.
- A transient lazy resolver containing the non-serializable filesystem-view supplier.

Then force resolution only when Java serialization actually occurs.

```java
import java.io.IOException;
import java.io.ObjectOutputStream;

@Getter(AccessLevel.NONE)
private volatile Map<String, PrevFilePaths> prevFilePaths;

@Getter(AccessLevel.NONE)
private final transient Lazy<Map<String, PrevFilePaths>> prevFilePathsResolver;

Initialize them in the constructor:

this.prevFilePaths = null;
this.prevFilePathsResolver = Lazy.lazily(() ->
    HoodieWriteCommitCallbackUtil.resolvePrevFilePaths(
        hoodieWriteStat,
        fsViewSupplier == null ? null : fsViewSupplier.get()));

The getter memoizes the resolved value:

public Map<String, PrevFilePaths> getPrevFilePaths() {
  Map<String, PrevFilePaths> paths = prevFilePaths;
  if (paths == null) {
    Lazy<Map<String, PrevFilePaths>> resolver = prevFilePathsResolver;
    paths = resolver == null
        ? Collections.emptyMap()
        : resolver.get();

    prevFilePaths = paths == null
        ? Collections.emptyMap()
        : paths;
  }

  return prevFilePaths;
}

Finally, add the serialization hook:

private void writeObject(ObjectOutputStream out) throws IOException {
  // The resolver cannot cross the serialization boundary, so materialize
  // its value at the last possible moment.
  getPrevFilePaths();
  out.defaultWriteObject();
}

This gives you the desired lifecycle:

message construction
    ↓ no filesystem-view access
callback ignores prevFilePaths
    ↓ still no access
getPrevFilePaths() or JSON/Java serialization
    ↓ resolve once and memoize
deserialized message
    ↓ resolved map remains available; resolver is null

Do not clear prevFilePathsResolver manually after resolution. Hudi’s Lazy already clears its initializer, and keeping the Lazy reference avoids subtle concurrency races.

Update the serialization test to expect preservation:

@Test
public void javaSerializationResolvesAndPreservesPrevFilePaths()
    throws IOException, ClassNotFoundException {
  AtomicInteger lookups = new AtomicInteger();

  HoodieWriteCommitCallbackMessage message =
      new HoodieWriteCommitCallbackMessage(
          COMMIT_TIME, "table", "/base", updateStat(),
          Option.of("commit"), Option.empty(),
          () -> {
            lookups.incrementAndGet();
            return viewResolving(PREV_PATH);
          },
          Collections.emptyMap());

  assertEquals(0, lookups.get());

  HoodieWriteCommitCallbackMessage roundTripped =
      serializeAndDeserialize(message);

  assertEquals(1, lookups.get());
  assertEquals(
      PREV_PATH,
      roundTripped.getPrevFilePaths().get("f0").getBaseFilePath());
}

Keep the existing serialVersionUID. For compatibility with streams produced before this field existed, the getter’s resolver == null fallback returns an empty map.

This is the unavoidable serialization boundary: the filesystem view itself cannot be shipped, so Java serialization must materialize the lazy value. JSON callbacks already do this naturally because Jackson invokes getPrevFilePaths() while generating the payload. See the current [PR changes](https://github.com/apache/hudi/pull/18988/changes).

Thanks @danny0405. I'll take this and push the two-field version. One thing to correct though:

it seems the Ser/De customization is unavoidable. The PR description already claims this behavior, but the current implementation does not provide it...

That PR description was outdated. Nothing actually forces the behaviour. All three built-in callbacks (HTTP, Kafka, Pulsar) go through convertToJsonString, and Jackson invokes getPrevFilePaths() while generating the payload, so the JSON path resolves the paths either way. Nothing in the repo Java-serializes the message, and prevFilePaths is new in this PR, so no consumer can be depending on it yet. I had also tested after making this change.

But, i agree with your choice. The class is a @PublicAPIClass and implements Serializable, so a custom callback that ships the message across a JVM boundary would silently get an empty map rather than an error.

Got it, then the serialization custimization might just be the API compatibility instead of real use usage here.

yeah that's correct. Updated now. thanks
6c5d2d0