DanielLeens commented on PR #10801:
URL: https://github.com/apache/seatunnel/pull/10801#issuecomment-4968421738

   Rechecked the same unchanged head `b3059a897e0d` after the CI / merge-gate 
fact changed.
   
   ## Runtime path rechecked
   ```text
   user config
     -> env.sink.flush.interval = 5000
     -> SourceSeaTunnelTask.createSourceFlowLifeCycle() reads 
SINK_FLUSH_INTERVAL
     -> SourceFlowLifeCycle.hook() starts the flush timer
     -> SourceFlowLifeCycle.onTimerTick() sends FlushSignal
   
   engine signal delivery
     -> FlushSignal travels through serializer / queue / transform path
     -> SinkFlowLifeCycle.processSignal()
         -> writerContext.getFlushAction().run()
   
   JDBC single-table non-XA path
     -> JdbcSink.createWriter() takes the isExactlyOnce=false branch
     -> new JdbcSinkWriter(..., context, ...)
     -> JdbcSinkWriter constructor registers 
context.registerFlushAction(this::timerFlush)
     -> timerFlush() calls tryOpen(), checkFlushException(), flush(), and 
commits when auto-commit is disabled
   
   JDBC multi-table path
     -> MultiTableSink creates child writers with SinkContextProxy
     -> child writers register their flush actions into the proxies
     -> MultiTableSink.registerAggregatedFlushIfNeeded() registers one parent 
aggregated action
     -> MultiTableSinkWriter.aggregatedFlush()
         -> drains queues
         -> checks sub-sink errors
         -> runs child flush actions under the existing runnable locks
   
   JDBC exactly-once path
     -> JdbcSink.createWriter() takes the XA writer branch
     -> no flush action is registered
     -> this matches the docs: timer flush is not supported with 
is_exactly_once=true
   ```
   
   ## Merge conclusion
   ### Conclusion: source blocker cleared from Daniel's side
   
   1. Blocking items
   - None from Daniel's source review on this unchanged head.
   
   2. Current gate
   - The current CI signal is now green: 
https://github.com/apache/seatunnel/actions/runs/29266711328/job/86873921850
   - Daniel only has `READ` permission on this repository, so GitHub may still 
show earlier review state and a write-capable maintainer may still need to 
handle the final approval / dismissal step.
   
   I do not see a reopened code-side blocker from Daniel on the current head.
   


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