nankeChen75 commented on issue #9583:
URL: https://github.com/apache/seatunnel/issues/9583#issuecomment-5994115155

   Thanks for the guidance. I have completed the reproduction checks and 
prepared a minimal backport based on `2.3.13-release`.
   
   **Reproduction on 2.3.11**
   
   Using a minimal FakeSource → TableFilter (EXCLUDE) → Console job, filtering 
out every table causes the job to exit with code 1:
   ```
   org.apache.seatunnel.core.starter.exception.CommandExecuteException: 
SeaTunnel job executed failed
       at 
org.apache.seatunnel.core.starter.seatunnel.command.ClientExecuteCommand.execute(ClientExecuteCommand.java:228)
       at org.apache.seatunnel.core.starter.SeaTunnel.run(SeaTunnel.java:40)
       at 
org.apache.seatunnel.core.starter.seatunnel.SeaTunnelClient.main(SeaTunnelClient.java:40)
   Caused by: java.lang.IndexOutOfBoundsException: Index 0 out of bounds for 
length 0
       at 
java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
       at 
java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
       at 
java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:266)
       at java.base/java.util.Objects.checkIndex(Objects.java:361)
       at java.base/java.util.ArrayList.get(ArrayList.java:427)
       at 
org.apache.seatunnel.engine.core.parse.MultipleTableJobConfigParser.tryGenerateMultiTableSink(MultipleTableJobConfigParser.java:642)
       at 
org.apache.seatunnel.engine.core.parse.MultipleTableJobConfigParser.parseSink(MultipleTableJobConfigParser.java:605)
       at 
org.apache.seatunnel.engine.core.parse.MultipleTableJobConfigParser.parse(MultipleTableJobConfigParser.java:240)
       at 
org.apache.seatunnel.engine.client.job.ClientJobExecutionEnvironment.getLogicalDag(ClientJobExecutionEnvironment.java:123)
       at 
org.apache.seatunnel.engine.client.job.ClientJobExecutionEnvironment.execute(ClientJobExecutionEnvironment.java:191)
       at 
org.apache.seatunnel.core.starter.seatunnel.command.ClientExecuteCommand.execute(ClientExecuteCommand.java:165)
       ... 2 more
   ```
   The complete credential-free reproduction configuration is:
   ```
       env {
         parallelism = 1
         job.mode = "BATCH"
       }
   
       source {
         FakeSource {
           plugin_output = "source1"
           tables_configs = [
             {
               row.num = 1
               schema = {
                 table = "test.student"
                 columns = [
                   { name = "id", type = "int" }
                 ]
               }
             }
           ]
         }
       }
   
       transform {
         TableFilter {
           plugin_input = "source1"
           plugin_output = "filtered"
           database_pattern = "test"
           table_pattern = "student"
           pattern_mode = "EXCLUDE"
         }
       }
   
       sink {
         console {
           plugin_input = "filtered"
         }
       }
   ```
   
   **Partial filtering**
   
   I also tested three source tables: student (1 row), teacher (3 rows), and 
course (2 rows). Using only `table_pattern = "student"` with
   `pattern_mode = "EXCLUDE"` leaves teacher and course.
   
   The logs confirm that the execution plan contains `console-MultiTableSink`, 
that `MultiTableSinkWriter` is initialized, and that Console writes exactly 3 
teacher rows and 2 course rows. The job finishes with `FINISHED`.
   
   **Backport and regression coverage**
   
   The original fix is part of a much larger table-level fault-isolation 
change, so I did not cherry-pick the whole commit. Instead, I backported only 
the minimal `sinkActions.isEmpty()` guard relevant to this issue.
   
   I added:
   - A parser unit test asserting that filtering all tables produces no sink 
actions.
   - A Zeta integration test with an all-filtered branch alongside a retained 
multi-table branch. The assertions verify the exact row counts for the retained 
tables.
   
   Both new tests fail with `IndexOutOfBoundsException` when the guard is 
removed and pass when it is restored. For the integration test, I rebuilt the 
starter JAR before each run to verify the actual container-executed code.
   
   Formatting and build verification have also completed successfully.
   
   These results cover the empty-sinkActions failure and partial filtering in 
the minimal reproduction; they do not establish that every symptom
   in the original MySQL-CDC → StarRocks report has the same cause.
   
   I will open the backport PR and link it here. Please let me know if 
`2.3.13-release` is not the intended target branch.


-- 
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]

Reply via email to