zhangshenghang opened a new pull request, #12941:
URL: https://github.com/apache/seatunnel/pull/12941
Yes, I am contributing to Apache SeaTunnel.
## What documentation issues were found
While auditing connector, transform and common-options documentation against
the actual Java source code (option definitions, factory `optionRule()`s, type
mappers and option-consumption code), I found the following real inaccuracies:
1. **Pulsar source (en + zh)** — The FAQ claimed only `EARLIEST`/`LATEST`
startup modes are supported, contradicting the option table and
`PulsarSourceOptions.StartMode` (`EARLIEST`, `LATEST`, `SUBSCRIPTION`,
`TIMESTAMP`). It also claimed consumers join with configurable subscription
types (e.g. `Failover`/`Exclusive`), but no such option exists —
`PulsarConfigUtil.createConsumerBuilder` only sets the subscription name.
2. **Kudu source & sink type mapping (en + zh)** — Source table claimed
`INT8/INT16/INT32 → INT`; `KuduTypeMapper` actually maps `INT8 → TINYINT`,
`INT16 → SMALLINT`, `INT32 → INT`. Sink table claimed `INT → INT8/INT16/INT32`;
`KuduRowSerializer` passes values through unchanged, so the Kudu client's exact
boxed types mean `TINYINT → INT8`, `SMALLINT → INT16`, `INT → INT32`.
3. **Splunk source (en + zh)** — `params` was marked required, but
`SplunkSourceFactory.optionRule()` lists it as optional and
`SplunkSourceParameter` never validates it. Also documented that `output_mode`
defaults to `json` (set via `putIfAbsent`).
4. **Prometheus sink (en + zh)** — `retry` was documented with default `3`;
the option is defined with `noDefaultValue()` and the effective default is `0`
(retries disabled).
5. **Fluss sink (zh only)** — The zh "replicate CDC across databases"
section claimed `${schema_name}` resolves to the upstream database in a
Fluss-to-Fluss topology and used `database = "sink_db_${schema_name}"`. Fluss
identifiers carry no schema (`TableIdentifier.of(..., database, null, table)`),
so `${schema_name}` resolves to an empty string; the section now matches the
already-correct en page and uses `${database_name}`.
6. **Sink common options (en + zh)** — `plugin_input` was documented as
`String`, but `ConnectorCommonOptions.PLUGIN_INPUT` is a `listType()` option; a
single name or an array is accepted and multiple names are unioned by the Zeta
sink parser. The en-only "Important note" claimed a nonexistent `plugin_input`
→ `plugin_output` requirement (and contradicted the correct closing note), and
the examples used the invalid plugin name `FakeSourceStream` plus a nonexistent
`field_name` option.
7. **Source common options (en + zh)** — Same invalid `FakeSourceStream`
plugin name, and the same false "must set plugin_input" note (a source never
takes `plugin_input`).
8. **Sink write modes (en + zh)** — The file-connector save-mode support
table missed `GcsFile` (its factory exposes
`schema_save_mode`/`data_save_mode`) and `OssJindoFile` (does not expose them);
the troubleshooting section also omitted `SmbFile` and `GcsFile` from the
supported list. All entries re-verified against each `*SinkFactory`.
9. **LLM transform (en + zh)** — `api_key` was marked unconditionally
required, but `LLMTransformFactory` makes it conditionally required
(`OPENAI`/`DOUBAO`/`MICROSOFT`) and unused for `CUSTOM`, matching the page's
own CUSTOM note.
I also evaluated adding the shared `process_batch_size` / `model_retry_*` /
`model_request_timeout_ms` options to the LLM/Embedding pages, but verified in
`LLMTransform`/`EmbeddingTransform` runtime code that these are not consumed by
those transforms (LLM infers row-by-row; embedding batches via
`single_vectorized_input_number`), so documenting them would be misleading and
they were intentionally left out.
## What was changed
Only documentation corrections — no code changes. Every fix was verified
against the corresponding source file before editing.
## Files updated (19 files, en + zh kept in sync)
- `docs/{en,zh}/connectors/source/Pulsar.md`
- `docs/{en,zh}/connectors/source/Kudu.md`,
`docs/{en,zh}/connectors/sink/Kudu.md`
- `docs/{en,zh}/connectors/source/Splunk.md`
- `docs/{en,zh}/connectors/sink/Prometheus.md`
- `docs/zh/connectors/sink/Fluss.md`
- `docs/{en,zh}/transforms/llm.md`
- `docs/{en,zh}/connectors/common-options/source-common-options.md`
- `docs/{en,zh}/connectors/common-options/sink-common-options.md`
- `docs/{en,zh}/connectors/common-options/sink-write-modes.md`
## Were English and Chinese docs both checked?
Yes. Every issue was checked in both locales and fixed in both where
present. The Fluss `${schema_name}` issue existed only in the zh page (en was
already correct), and the false sink-common-options "Important note" existed
only in en (zh has no such note); both were handled accordingly.
## Duplicate PR check (last 7 days)
I checked open PRs from the last 7 days by author and community before
starting: #12932 (Zeta REST/engine/transforms/FAQ), #12911
(Kafka/Hive/Jdbc/ClickHouse/Doris/StarRocks/MongoDB/TDengine/…), #12865
(DynamoDB/Elasticsearch/Http/JDBC dialects/…), #12813
(Sls/Snowflake/Redis/CDC/…), #12771 (CDC/InfluxDB/S3/Gcs/Feishu/…), #12730
(file sinks/Iceberg source/LocalFile/…) and community PRs #12859, #12856. None
of them touches Pulsar, Kudu, Splunk, Prometheus, Fluss sink, llm transform, or
the common-options / sink-write-modes pages edited here, so this PR does not
overlap with them.
## Verification
- Re-verified every documented value against the source (option definitions,
factory option rules, `KuduTypeMapper`, `KuduRowSerializer`,
`SplunkSourceParameter`, `SubscriptionStartCursor`, `GcsFileSinkFactory`, etc.)
before editing.
- Ran the CI-equivalent `[email protected] -c .dlc.json` on all 19
changed files: 0 failures.
- Validated markdown table column consistency across all changed tables and
that all relative links resolve locally.
- `./mvnw spotless` was not run because this PR contains no Java changes
(spotless is configured for Java only).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
