More tasks than partitions
tasks.max above the topic's partition count, so the extra tasks do nothing
{"connector.class":"io.confluent.connect.jdbc.JdbcSinkConnector","tasks.max":"12","topics":"orders"}Check a Kafka Connect connector config for the mistakes that do not raise an error: a Filter with no predicate, a transformation missing from the transforms list, errors.tolerance=all with nowhere for bad records to go, and a literal password destined for the config topic.
Partitions cap a sink's useful tasks.max; leave it 0 to skip
that check. The broker count matters for the dead letter topic, whose
replication factor defaults to 3 and fails to create on a smaller cluster.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Validate. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
tasks.max above the topic's partition count, so the extra tasks do nothing
{"connector.class":"io.confluent.connect.jdbc.JdbcSinkConnector","tasks.max":"12","topics":"orders"}The settings a source needs, and the ones only a sink uses
{"name":"pg-source","connector.class":"io.debezium.connector.postgresql.PostgresConnector","tasks.max":"1","database.hostname":"pg"}These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
A sink cannot use more tasks than the topic has partitions, and a source is limited by what it can split.
Instead:Match tasks.max to partitions for a sink.
A connector posted without a name is rejected, and the error is about the request body rather than the field.
Instead:Include name at the top level, outside config, when posting to the REST API.
One bad record stops the connector entirely, which for a stream of mixed data is an outage.
Instead:Set errors.tolerance: all with a dead letter queue, so bad records are kept rather than dropped.
Connect validates the settings it owns and accepts a great deal that then does nothing, or does something destructive. Those are the ones worth checking before a deploy.
The Filter transformation drops the records its predicate matches. With no predicate it matches every record, so the connector runs, reports RUNNING, consumes the topic and writes nothing. There is no error and no dead letter record, because from Connect's point of view nothing failed. This is the most destructive Connect misconfiguration that produces no signal at all, and it is one missing line away from a working config.
transforms=dropTest
transforms.dropTest.type=org.apache.kafka.connect.\
transforms.Filter
# no transforms.dropTest.predicate
# -> every record dropped, connector healthy The transforms list is both the set and the order. Settings for an alias that is not in it are perfectly valid, perfectly inert, and completely silent: the config is accepted, the connector runs, and the transformation you configured does nothing. It usually happens when an alias is renamed in one place and not the other, and it looks identical to a transformation that is running and having no effect.
With tolerance all and no dead letter topic, a record that fails conversion or a transformation is discarded and the task carries on. The connector stays RUNNING, no metric moves in a way anyone alerts on, and the only trace is a log line if errors.log.enable happens to be on. Pair the tolerance with a dead letter topic and context headers, and give that topic a short retention: it is a diagnostic buffer, not a store.
schemas.enable defaults to true, which means JsonConverter expects and produces {"schema": {...}, "payload": {...}} rather than plain JSON. A sink reading ordinary JSON fails to deserialize; a source writes records that look wrong to every other consumer of the topic. The default is the surprising direction, and the setting has to be repeated per side: setting it for value does nothing for key.
Connect stores connector configs in its config topic in plain text and serves them from the REST API to anything that can reach the worker. A password in a connector config is therefore in a Kafka topic, in every backup of it, and in the topic's history even after the connector is deleted. Config providers exist for this: a ${file:...} reference is resolved by the worker at task start and never stored. This page names the settings that look like credentials and never prints their values.
Only the framework keys. A connector declares its own settings, so validating those needs the plugin installed, and anything unrecognised here is reported as belonging to the plugin rather than as a mistake. Connect's own endpoint does the rest: PUT /connector-plugins/<class>/config/validate against a worker that has the plugin returns per-setting errors and recommended values.