produce_message
Write one or more messages to existing Kafka topics, including content no producer sent, and encode values to Schema Registry schemas. Use it to inject or repair records; writes require confirm.
Instructions
Write 1 to 500 new messages in one call through items, or any number from an upload, to existing topics on this or another configured cluster. The caller supplies the key, value and headers, so unlike copy_message this can write content no producer ever sent. Writing one message is an items array of length one.
Every message carries provenance headers naming this tool, the time and the principal, so a fabricated message stays distinguishable from a genuine one.
upload sends a file on the user's own machine, one item per line as JSON, such as the file a transform_messages download saves. Over stdio the file is read at once; over HTTP the response is a link and a command to run there, once, as each run sends the file again. The file is never stored on the server, and the summary counts lines, shows a few examples and the failing lines by number. Without confirm the upload only checks the file.
Nothing is written unless confirm is true; one confirm covers the whole batch, and writing is not atomic because Kafka cannot retract a record produced before a later item failed. Results follow items order, each carrying index with result or error.
A produced message cannot be deleted: it stays until retention removes it, and any consumer reading the topic will process it. The destination must be writable and requires Kafka write permission; the endpoint you call may itself be read-only.
Omit partition unless the exact partition matters. The key decides placement, and naming a partition puts a keyed message where its key does not hash to, which breaks ordering for that key.
A topic whose consumers read Avro, Protobuf or JSON Schema needs value_schema: give the value as JSON and it is encoded to the destination registry's schema, refused with the offending field when it does not fit. A topic with a format configured in topic_formats is encoded to it without being asked. Check get_message or sample_messages first: a schema_id on the existing messages means the topic needs value_schema, and writing plain JSON there breaks its consumers.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| items | No | The messages to write, 1 to 500 of them. Writing one message is an array of length one. Two identical items mean two messages, which is allowed: appending the same payload twice is a real request. Give either items or upload, not both. | |
| upload | No | Optional. Instead of items, send messages from a file on the user's own machine. Over stdio the file is read right away and the response carries its summary in file; over HTTP the response is a link and a command, e.g. curl -T, to run there, which prints the summary. Run an upload command once: each run sends the file again. The file holds one item per line as JSON, with the same fields as an entry of items, such as the file transform_messages download saves. It is read as it uploads and never stored on the server. Use it for more messages than items allows, or for a set saved and inspected first. Without confirm the upload writes nothing and its response counts the valid lines and reports the invalid ones by line number; call again with confirm to send. Give either items or upload, not both. | |
| confirm | No | Optional. When false or omitted, nothing is written and the response shows the messages that would be produced. Must be true to actually write them. One confirm covers the whole batch. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | ||
| atomic | Yes | ||
| failed | Yes | ||
| upload | No | ||
| applied | Yes | ||
| results | Yes | ||
| succeeded | Yes |