Skip to content
Merged
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -59,7 +59,13 @@ public String getWriteableName() {

@Override
public TransportVersion getMinimalSupportedVersion() {
return TransportVersions.STREAMS_LOGS_SUPPORT;
return null;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure that it's safe to return null here? It has a few callers outside of the default implementation of supportsVersion(), including in AbstractNamedDiffable.diff() (directly or indirectly, on both code paths).

I see a couple of different patterns elsewhere in the codebase where supportVersion() is overridden.

  • MinimalServiceSettings.supportsVersion and ModelRegistryMetadata have the same logic to what you have here, and getMinimalSupportedVersion() returns the _8_19 version.
  • AggregateMetricDoubleBlockBuilder, NoneChunkingSetting, and PinnedRankDoc make this method, e.g. the first of those does throw new UnsupportedOperationException("must not be called when overriding supportsVersion").
    (There's also TimeSeriesSourceOperator.Status where the two methods don't seem to agree on the minimal version, I haven't looked properly at that.)

If we're sure this method will never be called, I would prefer to throw an exception with an explicit message like e.g. AggregateMetricDoubleBlockBuilder does, so that if we're wrong we'll get something more helpful than an NPE somewhere later on. I don't know whether that or returning the _8_19 version is safer.

Hopefully someone from Core/Infra can sort us out here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We tried throwing an exception originally but it causes the tests to fail too. It seems returning TransportVersions.STREAMS_LOGS_SUPPORT_8_19 fixes the test fails so that looks to be like it's the right path possibly?

Copy link
Member

@PeteGillinElastic PeteGillinElastic Jun 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since there is a precedent for doing it, it fixes the tests, let's maybe go with this and see what Core/Infra have to say.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, I'm throwing an exception in this somewhat related PR, and that works fine.

}

@Override
public boolean supportsVersion(TransportVersion version) {
return version.onOrAfter(TransportVersions.STREAMS_LOGS_SUPPORT)
|| version.isPatchFrom(TransportVersions.STREAMS_LOGS_SUPPORT_8_19);
}

public static NamedDiff<Metadata.ProjectCustom> readDiffFrom(StreamInput in) throws IOException {
Expand Down