[Umbrella][Improve] Migrate Connector/Transform Validation to Declarative OptionRule — Claim & Tracking

@ryanmeowy

We need community help to migrate connector and transform validation from imperative if/throw checks to declarative optionRule() + Conditions.*.

If the Issue column shows an existing issue number, please claim in that issue.
If the Issue column shows This issue, please comment here to claim it.

Prerequisites / Framework Status

Phase 1 (framework) has been completed:

Design and scope audit: [STIP-28][Feature][Zeta] Enhance OptionRule to support rich declarative validation beyond presence checks #10976
Framework implementation: [STIP-28][Feature][Zeta] Enhance OptionRule to support rich declarative validation beyond presence checks #10977

This umbrella issue is for Phase 2 migration and tracking only.

Migration Guide

A. Numeric range

Use declarative constraints for rules like port > 0, batchSize >= 0.

import static org.apache.seatunnel.api.configuration.util.Conditions.greaterThan;

OptionRule.builder()
    .required(PORT, greaterThan(PORT, 0))
    .build();

B1. Required cross-field comparison

Use when both fields are mandatory and have relation constraints.

import static org.apache.seatunnel.api.configuration.util.Conditions.lessThanField;

OptionRule.builder()
    .required(START_TIMESTAMP, END_TIMESTAMP, lessThanField(START_TIMESTAMP, END_TIMESTAMP))
    .build();

B2. Optional cross-field comparison

Use when fields are not mandatory, but must satisfy relation when present.

import static org.apache.seatunnel.api.configuration.util.Conditions.lessOrEqualField;

OptionRule.builder()
    .optional(MIN_VALUE, MAX_VALUE, lessOrEqualField(MIN_VALUE, MAX_VALUE))
    .build();

Do not accidentally convert optional semantics into required semantics.

C. Conditional value check

Use when a trigger option enables another constraint.

import static org.apache.seatunnel.api.configuration.util.Conditions.greaterThan;

OptionRule.builder()
    .conditional(
        IGNORE_NO_LEADER_PARTITION,
        true,
        greaterThan(PARTITION_DISCOVERY_INTERVAL_MILLIS, 0))
    .build();

D1. Deprecated key coexistence (`withFallbackKeys` → `exclusive`)

When migrating a deprecated key to a new key name, replace withFallbackKeys + runtime
sourceMap mutual-exclusion check with exclusive(), so the conflict is caught at
--check time rather than silently at runtime.

Before:

public static final Option<List<String>> KEY_REPLACE_FIELDS =
        Options.key("replace_fields").listType().noDefaultValue()
                .withFallbackKeys("replace_field");

// runtime sourceMap check, invisible to --check
Map<String, Object> sourceMap = config.getSourceMap();
if (sourceMap.containsKey("replace_field") && sourceMap.containsKey("replace_fields")) {
    throw ...;
}

this.replaceFields.addAll(getRequiredOption(config, KEY_REPLACE_FIELDS));

After:

@Deprecated
public static final Option<List<String>> KEY_REPLACE_FIELD =
        Options.key("replace_field").listType().noDefaultValue();

public static final Option<List<String>> KEY_REPLACE_FIELDS =
        Options.key("replace_fields").listType().noDefaultValue();

// exclusive() validates at --check time: exactly one must be present
OptionRule.builder()
    .exclusive(KEY_REPLACE_FIELD, KEY_REPLACE_FIELDS)
    .build();

if (config.getOptional(KEY_REPLACE_FIELDS).isPresent()) {
    this.fields = config.get(KEY_REPLACE_FIELDS);
} else {
    this.fields = config.get(KEY_REPLACE_FIELD);
}

D2. Exclusive with value constraints

Use when exclusive options also need content validation (e.g. non-empty).

Framework support:

PR #11010 — Map condition validators: mapNotEmpty, mapContainsKey, mapContainsKeys (merged)

PR #11022 — Allow exclusive/bundled + optional(condition) coexistence (merged)

Before:

// runtime imperative checks — invisible to --check
if (config.get(SCHEMA) != null && config.get(TABLE_CONFIGS) != null) {
    throw new IllegalArgumentException("Cannot specify both 'schema' and 'table_configs'");
}
if (config.get(SCHEMA) != null && config.get(SCHEMA).isEmpty()) {
    throw new IllegalArgumentException("'schema' must not be empty");
}

After:

import static org.apache.seatunnel.api.configuration.util.Conditions.mapNotEmpty;
import static org.apache.seatunnel.api.configuration.util.Conditions.notEmpty;

OptionRule.builder()
    .exclusive(SCHEMA, TABLE_CONFIGS)
    .optional(SCHEMA, mapNotEmpty(SCHEMA))
    .optional(TABLE_CONFIGS, notEmpty(TABLE_CONFIGS))
    .build();

exclusive() — exactly one must be present
optional(option, condition) — when present, value must satisfy the constraint
Both can coexist on the same option; constraints are only evaluated when the option is present

D3. Custom structural validation (`ConditionExtension`)

Use when built-in operators cannot express the validation — for example, validating internal structure of List<Map<String, Object>>, or enforcing constraints across nested child configs like table_configs.

Framework support:

PR #11048 — ConditionOperator.EXTENSION + ConditionExtension<T> interface (merged)

Before:

// imperative structural check buried in buildWithConfig() — invisible to --check
for (Map<String, Object> child : tableConfigs) {
    if (!child.containsKey("table_name")) {
        throw new IllegalArgumentException("each table config must contain 'table_name'");
    }
}
// cross-element uniqueness check
if (tableNames.size() != new HashSet<>(tableNames).size()) {
    throw new IllegalArgumentException("table names must be unique");
}

After:

import org.apache.seatunnel.api.configuration.util.ConditionExtension;
import org.apache.seatunnel.api.configuration.util.Conditions;

static class TableConfigsValidator
        implements ConditionExtension<List<Map<String, Object>>> {
    @Override
    public String description() {
        return "each entry must contain a non-empty 'table_name', "
                + "and all table names must be unique";
    }

    @Override
    public boolean evaluate(ReadonlyConfig config, List<Map<String, Object>> value)
            throws OptionValidationException {
        if (value.isEmpty()) {
            return false;
        }
        Set<String> seen = new HashSet<>();
        for (Map<String, Object> entry : value) {
            Object name = entry.get("table_name");
            if (!(name instanceof String) || ((String) name).isEmpty()) {
                return false;
            }
            if (!seen.add((String) name)) {
                return false;
            }
        }
        return true;
    }
}

OptionRule.builder()
    .exclusive(TABLE_CONFIGS, SCHEMA)
    .optional(TABLE_CONFIGS,
            Conditions.extension(TABLE_CONFIGS, new TableConfigsValidator()))
    .build();

ConditionExtension<T> — implement description() (used in error messages and REST metadata) and evaluate() (validation logic, avoid I/O)
Conditions.extension(Option<T>, ConditionExtension<T>) — compile-time type binding between option and extension
Chains with .and() / .or() like any built-in operator
Return false for auto-composed error messages, or throw OptionValidationException for context-rich details

E. Keep runtime checks for cases not suitable for declarative rules

Do not migrate these into declarative rules:

external system/state validation (DB/metastore/network reachability)
complex parser/semantic validation (SQL parsing, advanced regex semantics)
runtime context checks (current time, execution topology state)

Connectors Open for Claim

Type	Connector	Contributer	Status	PR
Source	connector-cdc-base		Todo
Source	connector-cdc-mysql	@ryanmeowy	Merged	#12708
Source	connector-cdc-oceanbase	@ryanmeowy	Merged	#12708
Source	connector-cdc-mongodb	@ryanmeowy	Merged	#12735
Source	connector-cdc-postgres		Todo
Source	connector-cdc-oracle		Todo
Source	connector-cdc-sqlserver	@ZYZ666-RGB	Merged	#12764
Source	connector-cdc-db2		Todo
Source	connector-cdc-opengauss		Todo
Source	connector-cdc-tidb		Todo
Source	connector-cdc-vitess	@ryanmeowy	Merged	#12746
Source	connector-edge-socket	@nzw921rx	Merged	#11384
Source	connector-fake	@TianHengZhuang	Merged	#12404
Source	connector-google-sheets	@KaustAbhinand	Completed(no migration needed)	#11943
Source	connector-openmldb	@Nikk8091	Merged	#12181
Source	connector-web3j	@Nikk8091	Merged	#12180
Sink	connector-activemq	@Nikk8091	Merged	#12004
Sink	connector-aerospike	@hyoj-dev	Merged	#12090
Sink	connector-assert		Todo
Sink	connector-bigquery	@yigitcan-ozturk	Merged	#12272
Sink	connector-console	@asrajawat	Merged	#11477
Sink	connector-datahub	@yigitcan-ozturk	Merged	#12174
Sink	connector-dingtalk	@Nikk8091	Merged	#12170
Sink	connector-druid	@smoggy666	Merged	#12250
Sink	connector-email	@abolfazlmadanii	Merged	#11817
Sink	connector-fluss	@hutiefang76	Merged	#12422
Sink	connector-google-firestore	@1328837476-hug	Merged	#12278
Sink	connector-hugegraph	@Nikk8091	Merged	#12075
Sink	connector-hudi	@zhang-arvin	Completed(no migration needed)
Sink	connector-lance	@ZYZ666-RGB	Merged	#12222
Sink	connector-mqtt	@ealeonraz	In review	#11461
Sink	connector-s3-redshift	@yigitcan-ozturk	Merged	#12274
Sink	connector-selectdb-cloud	@Nikk8091	Merged	#12351
Sink	connector-sensorsdata	@Nikk8091	Merged	#12315
Sink	connector-sentry	@yigitcan-ozturk	Merged	#12148
Sink	connector-slack	@1328837476-hug	Merged	#12178
Both	connector-amazondynamodb	@goutamadwant	Merged	#11821
Both	connector-amazonsqs	@xinnyuli	Merged	#12217
Both	connector-cassandra	@Aryadeepta	Merged	#11964
Both	connector-clickhouse	@yigitcan-ozturk	Merged	#12574
Both	connector-databend	@BobSong-dev	Merged	#11831
Both	connector-doris	@zhang-arvin	Merged	#11858
Both	connector-easysearch	@TianHengZhuang	Merged	#12414
Both	connector-elasticsearch	@nzw921rx	Merged	#11122
Both	connector-file	@RohanExploit	Merged	#11881
Both	connector-graphql	@KaustAbhinand	Merged	#12273
Both	connector-hbase	@goutamadwant	Merged	#11803
Both	connector-hive	@zhang-arvin	Completed(no migration needed)
Both	connector-http	@1328837476-hug	Merged	#12773
Both	connector-iceberg	@ClaireLytt	Merged	#11921
Both	connector-influxdb	@erica1111-prog	Claimed
Both	connector-iotdb	@Nikk8091	Merged	#12603
Both	connector-iotdb-v2	@liziing	Merged	#11839
Both	connector-jdbc	@nzw921rx	Merged	#11106
Both	connector-kafka	@nzw921rx	Merged	#11157
Both	connector-kudu	@avnijainnn	In review	#12607
Both	connector-maxcompute	@1328837476-hug	Merged(missing sink)	#12690
Both	connector-milvus	@ZYZ666-RGB	Merged	#11504
Both	connector-mongodb	@AmanMishra1996	Merged	#11886
Both	connector-neo4j	@jjj-n	Merged	#12047
Both	connector-paimon	@karthik-0306	Merged	#12573
Both	connector-prometheus	@goutamadwant	Merged	#11738
Both	connector-pulsar	@Linz1248	Merged	#11985
Both	connector-qdrant	@yigitcan-ozturk	Completed(no migration needed)
Both	connector-rabbitmq	@cyl-uuu	Merged	#11795, #12519
Both	connector-redis	@ss666	Merged	#11225
Both	connector-rocketmq	@nzw921rx	Merged	#11158
Both	connector-sls	@Nikk8091	Merged	#12352
Both	connector-socket	@nzw921rx	Merged	#11214, follow-up #12572 open
Both	connector-starrocks	@zhang-arvin	Completed(no migration needed)
Both	connector-tablestore	@zeguilherme99	Merged	#12424
Both	connector-tdengine	@yigitcan-ozturk	Merged	#12490
Both	connector-typesense	@yigitcan-ozturk	Merged	#12175

Transforms Open for Claim

Type	Transform	Contributer	Status	PR
Transform	CopyField	@nzw921rx	Merged	#11095
Transform	DataValidator	@nzw921rx	Merged	#11095
Transform	DynamicCompile	@nzw921rx	Merged	#11095
Transform	FieldEncrypt	@nzw921rx	Merged	#11095
Transform	FieldMapper	@nzw921rx	Merged	#11095
Transform	FilterField	@nzw921rx	Merged	#11095
Transform	FilterRowKind	@goutamadwant	Merged	#11763
Transform	JsonPath	@nzw921rx	Merged	#11095
Transform	Metadata	@nzw921rx	Merged	#11095
Transform	RegexExtract	@nzw921rx	Merged	#11095
Transform	Replace	@nzw921rx	Merged	#11095
Transform	RowKindExtractor	@nzw921rx	Merged	#11095
Transform	Split	@nzw921rx	Merged	#11095
Transform	SQL	@nzw921rx	Merged	#11095
Transform	TableFilter	@nzw921rx	Merged	#11095
Transform	TableMerge	@nzw921rx	Merged	#11095
Transform	DefineSinkType	@nzw921rx	Merged	#11095

Note

connector-common is a shared base module, not a standalone connector plugin, so it is excluded from claim rows.

How to Contribute

Pick a connector/transform: Choose one from the lists above.
Claim the task: Comment on this issue (for example: I would like to work on connector-kafka or I would like to work on FilterRowKind).
Implement:
- Migrate declarative-eligible validation rules from imperative if/throw to optionRule() + Conditions.*.
- Keep runtime-only validation in runtime code paths (*Config.java, sink/source initialization) when it depends on external state or execution context.
- Distinguish cross-field semantics explicitly:
  - required cross-field: required(A, B, lessThanField(A, B))
  - optional cross-field: optional(A, B, lessOrEqualField(A, B))
Reference:
- Framework scope and audit baseline: #10976
- Declarative framework implementation: #10977
Submit PR: Open a Pull Request against dev, and link it back to this issue.

Thank you for your contribution.
Please leave a message if you'd like to implement the declarative validation migration for any connector or transform.

Code of Conduct

I agree to follow this project's Code of Conduct.

I would like to work on connector-fake. Please assign it to me.

A very kindly reminder: Other contributors can pick it up if the related PR is not submitted within four weeks. ^-^

Here are some helpful resources to get started:

I would like to work on connector-cdc. Please assign it to me.

I would like to work on FilterRowKind.

@erica1111-prog — as nzw921rx replied, yes, connector-influxdb is open for you to look at.

Before opening a PR, could you post a short scope note here so it can be tracked like the other slices?

which part of connector-influxdb you intend to touch (Source vs. Sink factory, and which option(s)/validation rule),

the dev commit you inspected, and whether you searched open/closed PRs for an existing implementation of the same rule,

the test coverage you plan to add through the existing factory tests (e.g. valid / missing / blank / padded values) and whether the EN/ZH docs need a matching contract update.

Please keep it to one focused slice and leave unrelated InfluxDB runtime behavior unchanged. Once the scope note is up we can confirm it here; no assignment change is made yet.

Hi! Here is the scope note for this slice:

Target slice: connector-influxdb — InfluxDBSinkFactory. Migrated optionRule() to define the full configuration schema and validation rules for the sink connector:
- Required: URL, DATABASES.
- Mutually exclusive options: KEY_MEASUREMENT_RULE bundled with optional KEY_MEASUREMENT_FIELD vs. standalone KEY_MEASUREMENT_RULE.
- Optional settings: USERNAME, PASSWORD, BATCH_SIZE, BATCH_INTERVAL_MS, MAX_RETRIES, RETRY_BACKOFF_MULTIPLIER_MS, CONNECT_TIMEOUT_MS, SinkConnectorCommonOptions.MULTI_TABLE_SINK_REPLICA.
Inspection & Dedup:
- Inspected on current latest dev branch.
- Searched both open and closed PRs/Issues for InfluxDBSinkFactory and InfluxDB optionRule: no existing or duplicate PR implementing OptionRule for the InfluxDB sink factory was found.
Test coverage & Documentation:
- Added test cases in InfluxDBFactoryTest:
  - testSinkOptionRulesSuccess: validates successful rule resolution when all mandatory options (url, database) and valid configurations are provided.
  - testSinkOptionRuleMissingRequired: verifies that validation fails when required options are omitted.
  - testSinkOptionRuleMutualExclusion: verifies conflict handling for mutually exclusive options.
- Docs: Existing user-facing docs (EN/ZH) already list these options with their types; this migration only enforces the contract at the factory validation level (OptionRule), so no doc contract changes are required.

All changes are strictly isolated to InfluxDBSinkFactory and InfluxDBFactoryTest with zero runtime changes to the InfluxDB sink execution logic

@PHJ2000

@PHJ2000 — thanks for the detailed scope note. The MaxCompute Sink endpoint nonblank slice as you describe it is fine to proceed with: a Conditions.notBlank(ENDPOINT) on the already-required sink option, mirroring what MaxcomputeSourceFactory does, with everything else (project/table_name requirements, source rules, credential fallback, timeout/retry defaults and bounds, URL parsing, client construction, runtime checks) left untouched.

On ownership/conflicts: you noted #11586 is still open and touches the same sink factory, shared factory test and sink docs. Please leave a short comment on #11586 pointing to this slice so its author is aware, and plan to rebase once it lands rather than waiting on it to start. Keep your diff limited to the endpoint rule so the overlap stays trivial to resolve.

Concrete asks before/with the PR:

Base on dev (you inspected 0145209931a4fe6795bbcf64a827f0f75302a624; re-check against the tip when you open the PR) and reference this issue in the PR description.
Factory tests via ConfigValidator covering valid, missing, empty, whitespace-only and padded nonblank values, as you listed; confirm nonblank values keep passing unchanged.
Matching EN/ZH sink doc update for the endpoint contract, and the configuration-check coverage in the existing MaxCompute E2E suite.
Report base/head regression results, module tests, Spotless and verification output in the PR, and be explicit about which E2E cases you could actually run locally and which you could not.

No assignment change is made yet; once your PR is up we can link it here.

@nzw921rx

Hi @nzw921rx, @SEZ9 could I take up connector-cdc-oracle? I couldn't find anyone assigned to it.

@erica1111-prog

@erica1111-prog — thanks for posting the scope note, that covers most of what was asked. A few things before this slice is confirmed here:

Commit inspected: "current latest dev" isn't trackable — please post the exact dev commit SHA you inspected so the slice can be pinned the same way as the others.
Mutual-exclusion rule: the description reads as "KEY_MEASUREMENT_RULE bundled with optional KEY_MEASUREMENT_FIELD vs. standalone KEY_MEASUREMENT_RULE", which has KEY_MEASUREMENT_RULE on both sides. Could you restate precisely which options are in each exclusive group as you intend to encode them in optionRule()?
Test coverage: testSinkOptionRulesSuccess, testSinkOptionRuleMissingRequired and testSinkOptionRuleMutualExclusion look good. The earlier ask also mentioned blank / padded values for the required options (URL, DATABASES) — please say whether you plan to cover those in InfluxDBFactoryTest or whether you're deliberately keeping them out of this slice (either is fine, just make it explicit).
Docs: agreed that if EN/ZH already list these options with matching required/optional status, no contract change is needed — please just double-check the required/optional markers match what optionRule() will enforce.
Your comment appears to be cut off at "zero runti" — please repost the last part so the full note is on record.

Once those are in, the connector-influxdb sink slice can be confirmed here (no assignment change yet). Please keep the change limited to InfluxDBSinkFactory and InfluxDBFactoryTest, as you described.

I'm working on the connector-assert migration in #13095.

@KaustAbhinand

@KaustAbhinand — thanks for volunteering for connector-cdc-oracle. Nobody has claimed it in this thread so far, so it's open for you to look at.

Before opening a PR, could you post a short scope note here so the slice can be tracked like the others:

which factory/factories in connector-cdc-oracle you intend to touch (Source vs. Sink) and which option(s)/validation rule(s) you plan to add or tighten in optionRule(),
the dev commit you inspected, and whether you searched open/closed PRs for an existing implementation of the same rule,
the test coverage you plan to add through the existing factory tests (e.g. valid / missing / blank / padded values) and whether the EN/ZH docs need a matching contract update.

Please keep it to one focused slice and leave unrelated Oracle CDC runtime behavior unchanged. Once the scope note is up we can confirm it here; no assignment change is made yet.

@SEZ9

@KaustAbhinand — thanks for volunteering for connector-cdc-oracle. Nobody has claimed it in this thread so far, so it's open for you to look at.

Before opening a PR, could you post a short scope note here so the slice can be tracked like the others:

which factory/factories in connector-cdc-oracle you intend to touch (Source vs. Sink) and which option(s)/validation rule(s) you plan to add or tighten in optionRule(),

the dev commit you inspected, and whether you searched open/closed PRs for an existing implementation of the same rule,

the test coverage you plan to add through the existing factory tests (e.g. valid / missing / blank / padded values) and whether the EN/ZH docs need a matching contract update.

Please keep it to one focused slice and leave unrelated Oracle CDC runtime behavior unchanged. Once the scope note is up we can confirm it here; no assignment change is made yet.

Hi @SEZ9! Here is the scope note for connector-cdc-oracle.

Factories touched: OracleIncrementalSourceFactory (Source only — no Sink factory exists in connector-cdc-oracle). One file, optionRule() only; restoreSource() and all runtime classes stay untouched
Files changed: OracleIncrementalSourceFactory.java, OracleSourceConfig.java.

Rule(s) to add/tighten: migrate the three SCN guards currently enforced at runtime in OracleIncrementalSource.getOracleStartupConfig into optionRule() as ConditionExtensions:

Dev commit inspected: 914741b9

Test coverage: Extended OracleIncrementalSourceFactoryTest - with ConfigValidator cases — valid (SCN under specific), invalid (SCN under latest/initial/unset mode), invalid (file/pos under specific), plus the existing testSpecificStartupModeRequiresScn/RejectsInvalidScn which already pass.

Doc changes: None required

Connector-cdcd-oracle: Migrated under issue apache#11007

@SEZ9

@erica1111-prog — thanks for posting the scope note, that covers most of what was asked. A few things before this slice is confirmed here:

Commit inspected: "current latest dev" isn't trackable — please post the exact dev commit SHA you inspected so the slice can be pinned the same way as the others.

Mutual-exclusion rule: the description reads as "KEY_MEASUREMENT_RULE bundled with optional KEY_MEASUREMENT_FIELD vs. standalone KEY_MEASUREMENT_RULE", which has KEY_MEASUREMENT_RULE on both sides. Could you restate precisely which options are in each exclusive group as you intend to encode them in optionRule()?

Test coverage: testSinkOptionRulesSuccess, testSinkOptionRuleMissingRequired and testSinkOptionRuleMutualExclusion look good. The earlier ask also mentioned blank / padded values for the required options (URL, DATABASES) — please say whether you plan to cover those in InfluxDBFactoryTest or whether you're deliberately keeping them out of this slice (either is fine, just make it explicit).

Docs: agreed that if EN/ZH already list these options with matching required/optional status, no contract change is needed — please just double-check the required/optional markers match what optionRule() will enforce.

Your comment appears to be cut off at "zero runti" — please repost the last part so the full note is on record.

Once those are in, the connector-influxdb sink slice can be confirmed here (no assignment change yet). Please keep the change limited to InfluxDBSinkFactory and InfluxDBFactoryTest, as you described.

@SEZ9 Thanks for the detailed feedback! Here are the clarifications:

Exact dev commit SHA:
Inspected base commit: c875a87bd6fb238585dd6856c2c4233b6a8ece46
Precise Mutual-Exclusion Rule:
Apologies for the typo in the previous note. The mutually exclusive groups encoded in optionRule() are:
- Group A (Dynamic measurement): bundled KEY_MEASUREMENT_RULE with optional KEY_MEASUREMENT_FIELD
- Group B (Static measurement): standalone MEASUREMENT
  A sink configuration cannot supply both static MEASUREMENT and dynamic rule-based measurement simultaneously.
Blank / Padded Values Scope:
To keep this slice strictly isolated to structural OptionRule migration without introducing changes to underlying runtime URL/database connection parsing, blank/whitespace-only/padded string validation checks are deliberately kept out of this slice. The test coverage focuses strictly on:
- Valid configurations (happy path with required & optional options).
- Missing required options (URL, DATABASES).
- Mutual-exclusion / bundling conflicts between MEASUREMENT and KEY_MEASUREMENT_RULE.
Documentation Contract:
Double-checked both docs/en/connector-v2/sink/InfluxDB.md and docs/zh/connector-v2/sink/InfluxDB.md: url and database are already marked as required (yes), while measurement, key_measurement_rule, and optional connection/batching params are marked as optional (no). The contract strictly matches the rules enforced by optionRule(), so no doc updates are needed.
Complete Closing Note:
"All changes are strictly isolated to InfluxDBSinkFactory and InfluxDBFactoryTest with zero runtime changes to the InfluxDB sink execution logic."

Claiming this. I'll take a look and submit a fix PR soon! 🙏

@erica1111-prog

@erica1111-prog — thanks for the follow-up, and for pinning the base commit to c875a87bd6fb238585dd6856c2c4233b6a8ece46; that's trackable now.

On the mutual-exclusion rule: the restated grouping is clear — Group A is KEY_MEASUREMENT_RULE bundled with optional KEY_MEASUREMENT_FIELD, Group B is standalone MEASUREMENT, and a sink config can't supply both. That's what we'd expect optionRule() to encode for the connector-influxdb sink slice.

Two things are still open before this slice can be confirmed here:

Your point 3 on blank / padded values is cut off again at "blank/whitespace-only/padded string va". From the lead-in it sounds like you intend to keep those out of this slice to avoid touching runtime URL/database parsing — that's fine, but please repost the end of that sentence so the decision is explicit on record.
Points 4 (EN/ZH required/optional markers matching what optionRule() enforces) and 5 (the earlier note truncated at "zero runti") didn't make it into the reply. Please add a one-line confirmation for the docs check and the missing tail of the earlier note.

Once those are posted, the connector-influxdb sink slice (limited to InfluxDBSinkFactory and InfluxDBFactoryTest, as you described) can be confirmed here. No assignment change yet.

@Meganexxx — noted that connector-assert is being handled in #13095; no action needed here.

@SEZ9

@erica1111-prog — thanks for the follow-up, and for pinning the base commit to c875a87bd6fb238585dd6856c2c4233b6a8ece46; that's trackable now.

On the mutual-exclusion rule: the restated grouping is clear — Group A is KEY_MEASUREMENT_RULE bundled with optional KEY_MEASUREMENT_FIELD, Group B is standalone MEASUREMENT, and a sink config can't supply both. That's what we'd expect optionRule() to encode for the connector-influxdb sink slice.

Two things are still open before this slice can be confirmed here:

Your point 3 on blank / padded values is cut off again at "blank/whitespace-only/padded string va". From the lead-in it sounds like you intend to keep those out of this slice to avoid touching runtime URL/database parsing — that's fine, but please repost the end of that sentence so the decision is explicit on record.

Points 4 (EN/ZH required/optional markers matching what optionRule() enforces) and 5 (the earlier note truncated at "zero runti") didn't make it into the reply. Please add a one-line confirmation for the docs check and the missing tail of the earlier note.

Once those are posted, the connector-influxdb sink slice (limited to InfluxDBSinkFactory and InfluxDBFactoryTest, as you described) can be confirmed here. No assignment change yet.

@Meganexxx — noted that connector-assert is being handled in #13095; no action needed here.

@SEZ9 Apologies for the copy-paste truncation! Here are the remaining confirmations on record:

Blank / Padded Values: Deliberately kept out of this slice so we do not touch runtime URL/database parsing; tests cover valid configs, missing required options (URL, DATABASES), and mutual exclusion (MEASUREMENT vs KEY_MEASUREMENT_RULE).
Docs Contract: Confirmed that docs/en/connector-v2/sink/InfluxDB.md and docs/zh/connector-v2/sink/InfluxDB.md already match the required/optional markers enforced by optionRule(), so no doc updates are needed.
Scope Boundary: All changes are strictly isolated to InfluxDBSinkFactory and InfluxDBFactoryTest with zero runtime changes to the InfluxDB sink execution logic.

@erica1111-prog

@erica1111-prog — thanks, that closes the three open items for the connector-influxdb sink slice:

Blank / whitespace-only / padded values for URL and DATABASES are deliberately out of this slice so runtime URL/database parsing is untouched; coverage is valid configs, missing required options, and the MEASUREMENT vs KEY_MEASUREMENT_RULE mutual exclusion. Recorded.
Docs check confirmed: docs/en/connector-v2/sink/InfluxDB.md and docs/zh/connector-v2/sink/InfluxDB.md already match the required/optional markers optionRule() will enforce, so no doc changes. Recorded.
Scope boundary recorded: changes limited to InfluxDBSinkFactory and InfluxDBFactoryTest, zero runtime changes to sink execution logic, against base commit c875a87bd6fb238585dd6856c2c4233b6a8ece46.

With that, the connector-influxdb sink slice is confirmed for you here. When you open the PR, please link it back to this issue and keep it to the two files above as described.

@LeonxLJX — thanks for offering to help. Since the connector-influxdb sink slice is now confirmed for erica1111-prog, please post which connector/slice you intend to take before starting on a PR, so we avoid overlapping work. Once you name it, we can pin it the same way (base commit, option groups, test coverage, docs check).

Navigation Menu

Repository navigation

[Umbrella][Improve] Migrate Connector/Transform Validation to Declarative OptionRule — Claim & Tracking #11007

Prerequisites / Framework Status

Migration Guide

A. Numeric range

B1. Required cross-field comparison

B2. Optional cross-field comparison

C. Conditional value check

D1. Deprecated key coexistence (`withFallbackKeys` → `exclusive`)

D2. Exclusive with value constraints

D3. Custom structural validation (`ConditionExtension`)

E. Keep runtime checks for cases not suitable for declarative rules

Connectors Open for Claim

Transforms Open for Claim

Note

How to Contribute

Code of Conduct

237 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Umbrella][Improve] Migrate Connector/Transform Validation to Declarative OptionRule — Claim & Tracking #11007

Description

Prerequisites / Framework Status

Migration Guide

A. Numeric range

B1. Required cross-field comparison

B2. Optional cross-field comparison

C. Conditional value check

D1. Deprecated key coexistence (withFallbackKeys → exclusive)

D2. Exclusive with value constraints

D3. Custom structural validation (ConditionExtension)

E. Keep runtime checks for cases not suitable for declarative rules

Connectors Open for Claim

Transforms Open for Claim

Note

How to Contribute

Code of Conduct

Activity

Ayushkale11 commented on Jun 4, 2026

nzw921rx commented on Jun 4, 2026

nzw921rx commented on Jun 4, 2026

hyjcxy commented on Jun 4, 2026

237 remaining items

erica1111-prog commented on Oct 29, 2026

SEZ9 commented on Oct 30, 2026

KaustAbhinand commented on Oct 30, 2026

SEZ9 commented on Oct 31, 2026

Meganexxx commented on Nov 2, 2026

SEZ9 commented on Nov 3, 2026

KaustAbhinand commented on Nov 5, 2026

erica1111-prog commented on Nov 6, 2026

LeonxLJX commented on Nov 12, 2026

SEZ9 commented on Nov 12, 2026

erica1111-prog commented on Nov 14, 2026

SEZ9 commented on Nov 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

D1. Deprecated key coexistence (`withFallbackKeys` → `exclusive`)

D3. Custom structural validation (`ConditionExtension`)