SEPURI-SAI-KRISHNA opened a new pull request, #12406:
URL: https://github.com/apache/seatunnel/pull/12406
### Purpose of this pull request
Closes #12405, reported by @zixiao144.
The MQTT source cannot be submitted to Zeta. `MqttSource` is a
`SeaTunnelSource`, and `SeaTunnelSource` extends `Serializable`
(`SeaTunnelSource.java:39`), but it holds a configuration object that is not:
```java
public class MqttSource extends AbstractSingleSplitSource<SeaTunnelRow> {
private final MqttSourceConfig sourceConfig; // MqttSource.java:38
...
public class MqttSourceConfig { //
MqttSourceConfig.java:24, no Serializable
```
Serializing the logical DAG therefore throws `NotSerializableException`,
which Hazelcast reports as `Failed to serialize 'LogicalVertex'`. The job is
rejected before the source starts.
Every field of `MqttSourceConfig` is a `String`, `int` or `boolean`, so
nothing about its contents was the problem. Only the class declaration was
missing, and the fix is to add it along with a `serialVersionUID`.
### The sink is not affected, and I checked rather than assumed
`MqttSink` holds `ReadonlyConfig`, `SeaTunnelRowType` and `CatalogTable`.
All three implement `Serializable`, and the sink takes the configuration object
directly instead of wrapping it. I round-tripped an `MqttSink` locally and it
succeeds, so no change is needed there and none is made. That asymmetry, the
sink using `ReadonlyConfig` while the source wraps it, is the whole reason only
one side is broken.
### Does this PR introduce _any_ user-facing change?
Yes, in the sense that the MQTT source becomes usable on Zeta. It appears
never to have worked there since the source was added in #10935 on 2026-06-08.
No config option, default, or public API changes, and the sink is untouched.
### How was this patch tested?
`./mvnw -q -DskipTests verify -pl seatunnel-connectors-v2/connector-mqtt` on
JDK 11 passes, covering the enforcer checks, `spotless:check` and compilation.
`spotless:check` was also run separately with up-to-date caching disabled.
`./mvnw -pl seatunnel-connectors-v2/connector-mqtt test`: **32 tests, 0
failures, 0 errors**.
The regression test is added to the existing `MqttSourceTest` rather than a
new class. It writes an `MqttSource` through an `ObjectOutputStream` and reads
it back, which needs no broker.
It is a real regression test, not a passing formality. Against unmodified
`dev` it fails:
```
[ERROR] MqttSourceTest.testSourceIsJavaSerializable ยป NotSerializable
java.io.NotSerializableException:
org.apache.seatunnel.connectors.seatunnel.mqtt.source.MqttSourceConfig
```
and with the one-line change it passes. That is the same before-and-after I
used to confirm the diagnosis in the first place.
### On E2E coverage
I want to flag this against the convention that a change in an area with an
existing IT should update that IT, because the situation here is unusual.
`connector-mqtt-e2e` exists, but it contains exactly one class,
`MqttSinkIT`. There is no source IT. That absence is almost certainly why this
shipped: the only end-to-end coverage exercises the side of the connector that
works, so a source that cannot be submitted at all went unnoticed from #10935
in June until a user reported it.
I have not added a source IT in this PR. The defect is Java serialization of
the source object, which the unit test reproduces exactly and deterministically
with no broker, and a source IT is a meaningful new piece of test
infrastructure rather than an update to an existing one. I would rather land
the one-line fix with a test that provably catches it than hold it behind new
E2E scaffolding.
That said, I think a source IT is worth having precisely because its absence
hid this, and `MqttSinkIT` already stands up the broker container it would
need. I am happy to open that as a follow-up, or to add it here if you would
rather it came with the fix.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
