fix(streaming): correctly skip problematic table-function input

[BugenZhao]

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

See #19352. Close #19352.

---

The behavior for table function returning an error in streaming mode will become:

risingwave/src/stream/src/executor/project_set.rs

Lines 205 to 213 in c6d2ba8

	// When we encounter an error from one of the table functions,
	//
	// - if there are other successful table functions, `fully_consumed` will still be
	// set to `false`, a `NULL` will be set in the output row for the failed table function,
	// that's why we set `None` here.
	//
	// - if there are no other successful table functions (or we are the only table function),
	// `fully_consumed` will be set to `true`, we won't output the row at all but skip
	// the whole result set of the given row. Setting `None` here is no-op.

As described in #17156, there's currently a limitation that

If some rows have been output when the error occurs, these rows will not be reverted.

which behaves kind of strangely. Since it might be uncommon (?) for a table function to fail halfway, I prefer not to document this behavior.

Checklist

• I have written necessary rustdoc comments
• I have added necessary unit tests and integration tests
• All checks passed in ./risedev check (or alias, ./risedev c)

Documentation

• My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note

If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

[BugenZhao]

• test: vnode count chaos test in e2e madsim #19250
• fix(streaming): correctly skip problematic table-function input #19353 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[stdrc]

In which case it's considered as "exhausted"?

[BugenZhao]

When this condition doesn't meet:

if let Some((i, result)) = state.peek()
  && is_current_input(i)

i.e., the cursor of the state has moved to the next input.