Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion: report user errors and abort mv creation directly during backfilling? #13035

Open
TennyZhuang opened this issue Oct 24, 2023 · 8 comments
Assignees

Comments

@TennyZhuang
Copy link
Contributor

TennyZhuang commented Oct 24, 2023

Currently, we'll ignore and just warn all parsing and expression errors of streaming jobs (mview). It may be friendly for online jobs, but confusing for the mview creator.

It'll be better if the mview creation will be aborted when meeting errors during backfilling.

@github-actions github-actions bot added this to the release-1.4 milestone Oct 24, 2023
@TennyZhuang TennyZhuang changed the title Discussion: report error and abort mv creation directly during backfilling? Discussion: report user errors and abort mv creation directly during backfilling? Oct 24, 2023
@chenzl25
Copy link
Contributor

We have background ddl right now, for background ddl it seems we can't report user errors easily. Furthermore, we will have sink into table later. It also relies on backfilling, but it looks like it should not abort because it will cause a partial update. However, this idea is good for debugging, maybe we can apply it the the frontend mv creation and provide a system variable to let users decide which mode to use.

@kwannoel
Copy link
Contributor

+1 for system / session variable support

@fuyufjh

This comment was marked as resolved.

@xxchan
Copy link
Member

xxchan commented Mar 26, 2024

Can this be solved by #13108?

It seems this provided the reporting mechanism.

The main problem for this is that "parsing and expression errors" are ignored/tolerated, so they are not considered "errors", and will also not be propagated.

We might need to add a mechanism to change the behavior of error handling, like ignore when streaming, but report when backfilling. One challenge may be that the code for tolerating errors are scattered in many places.

@fuyufjh

This comment was marked as resolved.

@BugenZhao
Copy link
Member

We might need to add a mechanism to change the behavior of error handling, like ignore when streaming, but report when backfilling. One challenge may be that the code for tolerating errors are scattered in many places.

The idea makes sense to me, but it makes error-handling become a bit too difficult to explain to users. Prefer KISS now and keeping the behavior as slightly ignoring the parsing errors.

Is source error also the case? Somehow similar to #15587 (comment).

@kwannoel

This comment was marked as resolved.

@yezizp2012 yezizp2012 modified the milestones: release-1.8, release-1.9 Apr 8, 2024
@xxchan xxchan self-assigned this May 10, 2024
@xxchan
Copy link
Member

xxchan commented May 11, 2024

We might need to add a mechanism to change the behavior of error handling, like ignore when streaming, but report when backfilling. One challenge may be that the code for tolerating errors are scattered in many places.

The idea makes sense to me, but it makes error-handling become a bit too difficult to explain to users. Prefer KISS now and keeping the behavior as slightly ignoring the parsing errors.

Per offline discussion: reporting error on backfilling is still useful.

  • Especially for source parsing error, now if users need to know whether parsing is correct, they have to check the logs, which is troublesome. The "strict mode" mechanism can offer better UX. https://github.com/orgs/risingwavelabs/discussions/16686#discussioncomment-9380613
  • On the other hand, there is no harm in reporting an error: the MV is still not visible, so it's ok to fails it. If the user really doesn't care about the error, the message can hint to bypass using non-blocking DDL.

Any updates?

I think not started yet. There are a few design problems to investigate.

@yezizp2012 yezizp2012 removed this from the release-2.0 milestone Aug 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants