SEPURI-SAI-KRISHNA commented on PR #12927: URL: https://github.com/apache/seatunnel/pull/12927#issuecomment-6349071841
Thanks for both notes. The sync is done, the protobuf follow-up is open, and the unit-test half of your informational item has a result. `kafka-connector-it` is still running. **Synced.** New head `dcc48f426`, merged from `df94fb07d`. Against `dev` as of writing it reads ahead 3 / behind 10, only because `dev` advanced ten commits after the merge. The diff is unchanged at 8 files, +286/-2. I checked the remedy, not just the merge: `cc54bb433` (#12938) is an ancestor, and `AbstractMultiCatalogTransform` here now carries `serialVersionUID = 7090258061839605137L` with `transformLevelConfig` transient. `Run / unit-test (17, windows-latest)` finished `BUILD SUCCESS` on this head, and the reactor built `SeaTunnel : Connectors V2 : Kafka` at `[128/329]` instead of stopping at Transforms V2. From that log: | Test class | Result | |---|---| | `LLMBooleanOutputTest` | Tests run: 42, Failures: 0, Errors: 0, Skipped: 0 | | `KafkaRecordEmitterTest` | Tests run: 6, Failures: 0, Errors: 0, Skipped: 0 | | `AvroSerializationSchemaTest` | Tests run: 8, Failures: 0, Errors: 0, Skipped: 0 | So `KafkaRecordEmitterTest` has been exercised by CI at last, the gap you flagged twice. Using your scoping rule: one lane, not the matrix. The other three `unit-test` legs are still running, so I claim the archived-wrapper failure cleared on `17, windows-latest` only. `kafka-connector-it` on 11 and 17 is still queued; I will post the result rather than infer it. On the previous head both legs passed (2h35m and 2h50m), so I expect the isolation to hold, but that is the old head. If `engine-v2-it` shows `testCheckpointsKeepCompletingUnderSustainedBackpressure` again I will treat it as the separate lane you described, under #12313 and #12316. **Protobuf follow-up, as requested: issue #12952 and PR #12953.** The scope matches what we agreed: a null-only guard, because an empty payload is a valid proto3 message of defaults rather than a tombstone. I measured both first. `null` gives `NullPointerException: Cannot read the array length because "data" is null` at `DynamicMessage.parseFrom`; `new byte[0]` decodes to a valid message. It also corrects `SchemaRegistryAwareProtobufDeserializationSchemaTest#throwsWhenMessageIsNull`, which had pinned the crash as intended behaviour, and documents the distinction in the EN and ZH docs. `compatible_kafka_connect_json` is still out of scope in both, for the same reason as before: I have not run it, so I will not assert an outcome for it. -- 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]
