Discuss: blocking DDL with sink_decouple might have bad UX

[xxchan]

Recently we made sink_decouple default to true for all sinks #17095. Previously we also make blocking DDL for sink defaults to true #15587.

Although they are orthogonal features:

• sink_decouple means writing to log store in SinkExecutor
• blocking DDL means wait for backfill in StreamScanExecutor

But it feels a little strange to me that when we use sink decouple and blocking DDL at the same time: we will wait for all data is backfilled into log store. In this case, user may not see the results are ready in sinks.

[fuyufjh]

What's the current behavior of create sink? Blocking or non-blocking?

[xxchan]

I think it's controlled by background_ddl, same as mv, so blocking

[fuyufjh]

I see. IMO, I feel the sink_decouple is mostly for decoupling failures or downstream, and should not affect the behavior of background_ddl.

May post this to Slack for wider disucssion

[fuyufjh]

Notes from Slack discussions:

• Target 1: If error happens, return the errors immediately
  • Should disable rewind during backfilling.
• Target 2: If no error, wait until all data are sinked before returning success to users
  • (Preferred) Option 1. Emit a barrier when the backfilling is over, and wait for the barrier to complete before returning success to users
    • Bonus: This idea can also be used to implement a FLUSH for sinks.
  • Option 2. Disable log store or set capacity to 0 or small number when doing backfilling.