SEZ9 commented on PR #12048: URL: https://github.com/apache/seatunnel/pull/12048#issuecomment-5770554326
Thanks for the update at `386d5c1ea`. Going through my earlier points against what is in the thread now: **Connection-string masking (PR12048-F3)** — the thread notes that `connection_string` moved out of `DEFAULT_SENSITIVE_KEYWORDS` into `DEFAULT_LOG_MASK_ONLY_KEYWORDS`, so it is masked in logs without entering the config-shade decrypt/encrypt path. That covers the log-masking half. To close this fully, could you confirm the other two output paths: the EntityPath-rejection error message does not echo the raw connection string, and the split / config `toString` do not include the live SAS key? For the remaining items I have no new information in the thread yet, so a code change or a short explanation for each would help: - **PR12048-F1 (High)** — a checkpointed sequence number that has been trimmed by retention currently fails the task on every restart. What is the operator's escape hatch? A documented option to reset to earliest/latest on a retention gap, or at minimum a documented procedure, would resolve this. - **PR12048-F2** — the shade relocations of `com.azure`, `io.netty` and `org.apache.qpid.proton` need a `ServicesResourceTransformer` so the Azure SDK's ServiceLoader providers still resolve after relocation. Please confirm it is present or add it. - **PR12048-F4** — the shaded jar embeds transitive Netty/Jackson/Proton versions chosen by the Azure SDK. Please pin them (or align them with SeaTunnel's dependency management) so CVE remediation does not have to chase versions hidden inside the connector. - **PR12048-F5** — rejecting connection strings that contain `EntityPath` blocks hub-scoped, least-privilege SAS policies. Could we accept it when it matches `event_hub_name` and only reject on mismatch? - **PR12048-F6** — `prefetch_count >= max_batch_size` should be validated at job submission in the factory, not at reader open on the worker. - **PR12048-F7** — partitions are discovered once; increasing the partition count at runtime silently loses data from the new partitions. Either periodic rediscovery or an explicit documented limitation is fine, but the docs should state which. - **PR12048-F8** — without connector-level reconnect/retry tuning, a transient AMQP outage beyond the SDK default retry window fails the whole task. Exposing the SDK retry options (or documenting the default window and behaviour) would address this. Once those are answered or pushed, I'll take another look. Thanks for the continued work on this. <!-- streview-comment:1226 --> -- 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]
