Skip to content

branch-4.1: [fix](streaming-job) reject silent-no-op ALTER keys and unsupported load.* properties #62680#62989

Open
github-actions[bot] wants to merge 1 commit intobranch-4.1from
auto-pick-62680-branch-4.1
Open

branch-4.1: [fix](streaming-job) reject silent-no-op ALTER keys and unsupported load.* properties #62680#62989
github-actions[bot] wants to merge 1 commit intobranch-4.1from
auto-pick-62680-branch-4.1

Conversation

@github-actions
Copy link
Copy Markdown
Contributor

@github-actions github-actions Bot commented May 2, 2026

Cherry-picked from #62680

…oad.* properties (#62680)

### What problem does this PR solve?

Three categories of CREATE/ALTER JOB properties are accepted by the
validator but silently ignored by the streaming runtime. Users set them,
see no error, yet observe no effect — an easy source of confusion and
hard-to-diagnose drift. Reject them upfront so the failure is visible.

1. **from-to path**: `schema` is a PG source-identity namespace (peer of
`database`). The TVF path (`checkUnmodifiableProperties` / `cdc_stream`)
already rejects it; the from-to path
(`checkUnmodifiableSourceProperties`)
   did not. Now aligned.
2. **cdc_stream TVF path**: `snapshot_split_key`, `snapshot_split_size`
   and `snapshot_parallelism` are materialized into split metadata
   (`remainingSplits`, `chunkHighWatermarkMap`) on first fetch and never
   re-read at runtime. ALTER on these is a silent no-op; reject.
3. **target properties (`load.*`)**:
`StreamingMultiTblTask#generateStreamLoadProps`
   only honors `load.max_filter_ratio` and `load.strict_mode`. Any other
   `load.*` (e.g. `load.where`, `load.columns`, `load.merge_type`) is
   accepted by `DataSourceConfigValidator.validateTarget` but dropped at
   runtime. Added an allow-list and reject unsupported `load.*` keys.
@github-actions github-actions Bot requested a review from yiguolei as a code owner May 2, 2026 00:06
@hello-stephen
Copy link
Copy Markdown
Contributor

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

  1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
  2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
  3. What features were added. Why was this function added?
  4. Which code was refactored and why was this part of the code refactored?
  5. Which functions were optimized and what is the difference before and after the optimization?

@hello-stephen
Copy link
Copy Markdown
Contributor

run buildall

@JNSimba
Copy link
Copy Markdown
Member

JNSimba commented May 2, 2026

run nonConcurrent

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants