Skip to content

DOC-2226: Sweep broken dotted-property xref anchors (idseparator migration) #1730

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Feediver1 wants to merge 2 commits into
base: main
Choose a base branch
from
+85 −90
Open

DOC-2226: Sweep broken dotted-property xref anchors (idseparator migration) #1730

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
5400c6c
fix(DOC-2226): sweep broken dotted-property xref anchors
Feediver1 Jun 4, 2026
87528a5
fix(DOC-2226): propagate anchor fixes to generated property partials
Feediver1 Jun 4, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
39 changes: 19 additions & 20 deletions docs-data/property-overrides.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -306,7 +306,7 @@
"cloud_storage_enable_segment_uploads": {
"description": "Controls the upload of log segments to Tiered Storage. If set to `false`, this property temporarily pauses all log segment uploads from the Redpanda cluster. When the uploads are paused, the <<cloud_storage_enable_remote_allow_gaps, `cloud_storage_enable_remote_allow_gaps`>> cluster configuration and `redpanda.remote.allowgaps` topic properties control local retention behavior.",
"related_topics": [
"xref:properties/topic-properties.adoc#redpandaremoteallowgaps[`redpanda.remote.allowgaps`]"
"xref:properties/topic-properties.adoc#redpanda-remote-allowgaps[`redpanda.remote.allowgaps`]"
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot Jun 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Normalize changed xrefs to full Antora resource IDs.

These updated links still use relative or non-prefixed targets (for example xref:./topic-properties.adoc..., xref:../cluster-properties.adoc..., and xref:properties/...). In this overrides file, these should be fully qualified (for example xref:reference:properties/topic-properties.adoc... and xref:reference:properties/cluster-properties.adoc...).

As per coding guidelines, "Always use full Antora resource IDs with module prefixes in xref links within property descriptions" and "Normalize all xref links in property-overrides.json to use full Antora resource IDs after updating".

Also applies to: 1251-1251, 1327-1327, 1351-1351, 1361-1361, 1367-1367, 1370-1370, 2051-2051

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs-data/property-overrides.json` at line 309, The xref entries in
property-overrides.json use non-prefixed targets (e.g.
"xref:properties/topic-properties.adoc#redpanda-remote-allowgaps[`redpanda.remote.allowgaps`]")
and must be normalized to full Antora resource IDs; update each affected xref
(including the occurrences referenced around lines with
"xref:properties/topic-properties.adoc", "xref:cluster-properties.adoc", and
other "xref:properties/..." matches noted in the comment) to use the
module-prefixed form like
"xref:reference:properties/topic-properties.adoc#...[`...`]" (or the appropriate
module prefix for cluster properties) so all links in property-overrides.json
are full Antora resource IDs. Ensure you replace every listed occurrence (1251,
1327, 1351, 1361, 1367, 1370, 2051 and the shown line) consistently.

]
},
"cloud_storage_enabled": {
Expand Down Expand Up @@ -1246,9 +1246,9 @@
},
"kafka_max_message_size_upper_limit_bytes": {
"related_topics": [
"xref:reference:properties/topic-properties.adoc#maxmessagebytes[`max.message.bytes`]"
"xref:reference:properties/topic-properties.adoc#max-message-bytes[`max.message.bytes`]"
],
"description": "The maximum value you can set for the xref:./topic-properties.adoc#maxmessagebytes[`max.message.bytes`] topic property. When set to `null`, no limit is enforced.",
"description": "The maximum value you can set for the xref:./topic-properties.adoc#max-message-bytes[`max.message.bytes`] topic property. When set to `null`, no limit is enforced.",
"config_scope": "cluster"
},
"kafka_nodelete_topics": {
Expand Down Expand Up @@ -1324,9 +1324,9 @@
"config_scope": "cluster"
},
"log_cleanup_policy": {
"description": "Default cleanup policy for topic logs.\n\nThe topic property xref:./topic-properties.adoc#cleanuppolicy[`cleanup.policy`] overrides the value of `log_cleanup_policy` at the topic level.",
"description": "Default cleanup policy for topic logs.\n\nThe topic property xref:./topic-properties.adoc#cleanup-policy[`cleanup.policy`] overrides the value of `log_cleanup_policy` at the topic level.",
"related_topics": [
"xref:reference:properties/topic-properties.adoc#cleanuppolicy[`cleanup.policy`]"
"xref:reference:properties/topic-properties.adoc#cleanup-policy[`cleanup.policy`]"
],
"config_scope": "cluster"
},
Expand All @@ -1348,28 +1348,28 @@
"config_scope": "cluster"
},
"log_compression_type": {
"description": "IMPORTANT: This property is ignored regardless of the value specified. The behavior is always the same as the `producer` value. Redpanda brokers do not compress or recompress data based on this property. If producers send compressed data, Redpanda stores it as-is; if producers send uncompressed data, Redpanda stores it uncompressed. Other listed values are accepted for Apache Kafka compatibility but are ignored by the broker. This property may appear in Admin API and `rpk topic describe` outputs for compatibility.\n\nDefault for the Kafka-compatible compression.type property. Redpanda does not recompress data.\n\nThe topic property xref:./topic-properties.adoc#compressiontype[`compression.type`] overrides the value of `log_compression_type` at the topic level.",
"description": "IMPORTANT: This property is ignored regardless of the value specified. The behavior is always the same as the `producer` value. Redpanda brokers do not compress or recompress data based on this property. If producers send compressed data, Redpanda stores it as-is; if producers send uncompressed data, Redpanda stores it uncompressed. Other listed values are accepted for Apache Kafka compatibility but are ignored by the broker. This property may appear in Admin API and `rpk topic describe` outputs for compatibility.\n\nDefault for the Kafka-compatible compression.type property. Redpanda does not recompress data.\n\nThe topic property xref:./topic-properties.adoc#compression-type[`compression.type`] overrides the value of `log_compression_type` at the topic level.",
"related_topics": [
"xref:reference:properties/topic-properties.adoc#compressiontype[`compression.type`]"
"xref:reference:properties/topic-properties.adoc#compression-type[`compression.type`]"
],
"config_scope": "cluster"
},
"log_message_timestamp_after_max_ms": {
"related_topics": [
"xref:reference:properties/topic-properties.adoc#messagetimestampaftermaxms[`message.timestamp.after.max.ms`]"
"xref:reference:properties/topic-properties.adoc#message-timestamp-after-max-ms[`message.timestamp.after.max.ms`]"
],
"description": "The maximum allowed time difference when a record's timestamp is in the future compared to the broker's clock. For topics using <<log_message_timestamp_type, `CreateTime`>> timestamps, Redpanda rejects records with timestamps that are too far in the future. This property has no effect on topics using <<log_message_timestamp_type, `AppendTime`>> timestamps. The topic property xref:./topic-properties.adoc#messagetimestampaftermaxms[`message.timestamp.after.max.ms`] overrides this cluster-level setting."
"description": "The maximum allowed time difference when a record's timestamp is in the future compared to the broker's clock. For topics using <<log_message_timestamp_type, `CreateTime`>> timestamps, Redpanda rejects records with timestamps that are too far in the future. This property has no effect on topics using <<log_message_timestamp_type, `AppendTime`>> timestamps. The topic property xref:./topic-properties.adoc#message-timestamp-after-max-ms[`message.timestamp.after.max.ms`] overrides this cluster-level setting."
},
"log_message_timestamp_before_max_ms": {
"related_topics": [
"xref:reference:properties/topic-properties.adoc#messagetimestampbeforemaxms[`message.timestamp.before.max.ms`]"
"xref:reference:properties/topic-properties.adoc#message-timestamp-before-max-ms[`message.timestamp.before.max.ms`]"
],
"description": "The maximum allowed time difference when a record's timestamp is in the past compared to the broker's clock. For topics using <<log_message_timestamp_type, `CreateTime`>> timestamps, Redpanda rejects records with timestamps that are too far in the past. This property has no effect on topics using <<log_message_timestamp_type, `AppendTime`>> timestamps. The topic property xref:./topic-properties.adoc#messagetimestampbeforemaxms[`message.timestamp.before.max.ms`] overrides this cluster-level setting."
"description": "The maximum allowed time difference when a record's timestamp is in the past compared to the broker's clock. For topics using <<log_message_timestamp_type, `CreateTime`>> timestamps, Redpanda rejects records with timestamps that are too far in the past. This property has no effect on topics using <<log_message_timestamp_type, `AppendTime`>> timestamps. The topic property xref:./topic-properties.adoc#message-timestamp-before-max-ms[`message.timestamp.before.max.ms`] overrides this cluster-level setting."
},
"log_message_timestamp_type": {
"description": "Default timestamp type for topic messages (CreateTime or LogAppendTime).\n\nThe topic property xref:./topic-properties.adoc#messagetimestamptype[`message.timestamp.type`] overrides the value of `log_message_timestamp_type` at the topic level.",
"description": "Default timestamp type for topic messages (CreateTime or LogAppendTime).\n\nThe topic property xref:./topic-properties.adoc#message-timestamp-type[`message.timestamp.type`] overrides the value of `log_message_timestamp_type` at the topic level.",
"related_topics": [
"xref:reference:properties/topic-properties.adoc#messagetimestamptype[`message.timestamp.type`]"
"xref:reference:properties/topic-properties.adoc#message-timestamp-type[`message.timestamp.type`]"
],
"config_scope": "cluster"
},
Expand All @@ -1383,7 +1383,7 @@
"log_segment_ms": {
"config_scope": "cluster",
"related_topics": [
"self-managed-only:xref:reference:properties/topic-properties.adoc#segmentms[`segment.ms`]"
"self-managed-only:xref:reference:properties/topic-properties.adoc#segment-ms[`segment.ms`]"
],
"description": "Default lifetime of log segments. If `null`, the property is disabled, and no default lifetime is set. Any value under 60 seconds (60000 ms) is rejected. This property can also be set in the Kafka API using the Kafka-compatible alias, `log.roll.ms`."
},
Expand Down Expand Up @@ -1418,7 +1418,7 @@
},
"max_compaction_lag_ms": {
"related_topics": [
"xref:reference:properties/topic-properties.adoc#max.compaction.lag.ms[`max.compaction.lag.ms`]"
"xref:reference:properties/topic-properties.adoc#max-compaction-lag-ms[`max.compaction.lag.ms`]"
],
"config_scope": "cluster"
},
Expand Down Expand Up @@ -1492,7 +1492,7 @@
},
"min_compaction_lag_ms": {
"related_topics": [
"xref:reference:properties/topic-properties.adoc#min.compaction.lag.ms[`min.compaction.lag.ms`]"
"xref:reference:properties/topic-properties.adoc#min-compaction-lag-ms[`min.compaction.lag.ms`]"
],
"config_scope": "cluster",
"description": "The minimum amount of time (in ms) that a log segment must remain unaltered before it can be compacted in a compact topic."
Expand Down Expand Up @@ -2048,8 +2048,7 @@
"schema_registry_replication_factor": {
"description": "Replication factor for internal `_schemas` topic. If unset, defaults to the xref:../cluster-properties.adoc#default_topic_replication[`default_topic_replication`] cluster property.",
"related_topics": [
"xref:../cluster-properties.adoc#default_topic_replication[`default_topic_replication`]",
"xref:../topic-properties.adoc#default_topic_replication[`default_topic_replication`]"
"xref:../cluster-properties.adoc#default_topic_replication[`default_topic_replication`]"
],
"config_scope": "broker",
"category": "schema-registry",
Expand Down Expand Up @@ -2276,11 +2275,11 @@
},
"write_caching_default": {
"related_topics": [
"xref:reference:properties/topic-properties.adoc#writecaching[`write.caching`]",
"xref:reference:properties/topic-properties.adoc#write-caching[`write.caching`]",
"xref:develop:manage-topics/config-topics.adoc#configure-write-caching[Write caching]"
],
"config_scope": "cluster",
"description": "The default write caching mode to apply to user topics. Write caching acknowledges a message as soon as it is received and acknowledged on a majority of brokers, without waiting for it to be written to disk. With `acks=all`, this provides lower latency while still ensuring that a majority of brokers acknowledge the write. \n\nFsyncs follow <<raft_replica_max_pending_flush_bytes,`raft_replica_max_pending_flush_bytes`>> and <<raft_replica_max_flush_delay_ms,`raft_replica_max_flush_delay_ms`>>, whichever is reached first.\n\nThe `write_caching_default` cluster property can be overridden with the xref:reference:properties/topic-properties.adoc#writecaching[`write.caching`] topic property."
"description": "The default write caching mode to apply to user topics. Write caching acknowledges a message as soon as it is received and acknowledged on a majority of brokers, without waiting for it to be written to disk. With `acks=all`, this provides lower latency while still ensuring that a majority of brokers acknowledge the write. \n\nFsyncs follow <<raft_replica_max_pending_flush_bytes,`raft_replica_max_pending_flush_bytes`>> and <<raft_replica_max_flush_delay_ms,`raft_replica_max_flush_delay_ms`>>, whichever is reached first.\n\nThe `write_caching_default` cluster property can be overridden with the xref:reference:properties/topic-properties.adoc#write-caching[`write.caching`] topic property."
},
"delete_topic_enable": {
"type": "boolean",
Expand Down
2 changes: 1 addition & 1 deletion modules/develop/pages/transactions.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -323,7 +323,7 @@ Different transactions require different approaches to handling failures within
Transactions are supported on topics with compaction configured. The compaction process removes aborted transaction data from the log. The resulting compacted segment contains only committed data batches (and potentially harmless gaps in the offsets due to skipped batches).

ifndef::env-cloud[]
At a cluster-level, compaction is set when xref:reference:cluster-properties.adoc#log_cleanup_policy[`log_cleanup_policy`] or xref:reference:topic-properties.adoc#cleanuppolicy[`cleanup.policy`] are set to either `compact` or `compact,delete`.
At a cluster-level, compaction is set when xref:reference:cluster-properties.adoc#log_cleanup_policy[`log_cleanup_policy`] or xref:reference:topic-properties.adoc#cleanup-policy[`cleanup.policy`] are set to either `compact` or `compact,delete`.
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot Jun 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Fix topic-properties xref path to the properties reference page.

Use xref:reference:properties/topic-properties.adoc#cleanup-policy[...] here for consistency with canonical property-reference links.

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@modules/develop/pages/transactions.adoc` at line 326, The topic-properties
xref is using the wrong path; update the link in the sentence that currently
uses xref:reference:topic-properties.adoc#cleanup-policy[...] to the canonical
properties reference path
xref:reference:properties/topic-properties.adoc#cleanup-policy[...] so the
cleanup.policy anchor points to properties/topic-properties.adoc instead of
topic-properties.adoc.


Optionally, you can enable removal of transactional control batches (commit and abort markers) during compaction by setting xref:reference:properties/cluster-properties.adoc#log_compaction_tx_batch_removal_enabled[`log_compaction_tx_batch_removal_enabled`] to `true`. When enabled, the topic's xref:reference:properties/topic-properties.adoc#delete-retention-ms[`delete.retention.ms`] setting is applied to these markers. For topics with a `compact` only cleanup policy, you must explicitly set `delete.retention.ms` at the topic level. This feature is not applied when Tiered Storage is enabled. See xref:manage:cluster-maintenance/compaction-settings.adoc#transactional-control-batch-removal[Transactional control batch removal].

Expand Down
2 changes: 1 addition & 1 deletion modules/get-started/pages/release-notes/redpanda.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -100,7 +100,7 @@ For end-to-end steps and prerequisites, see xref:manage:security/authentication.
**Storage mode:**

* xref:reference:properties/cluster-properties.adoc#default_redpanda_storage_mode[`default_redpanda_storage_mode`]: Set the default storage mode for new topics (`local`, `tiered`, `cloud`, or `unset`)
* xref:reference:properties/topic-properties.adoc#redpandastoragemode[`redpanda.storage.mode`]: Set the storage mode for an individual topic, superseding the legacy `redpanda.remote.read` and `redpanda.remote.write` properties
* xref:reference:properties/topic-properties.adoc#redpanda-storage-mode[`redpanda.storage.mode`]: Set the storage mode for an individual topic, superseding the legacy `redpanda.remote.read` and `redpanda.remote.write` properties

**Cloud Topics:**

Expand Down
10 changes: 5 additions & 5 deletions modules/manage/pages/cluster-maintenance/compaction-settings.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -20,7 +20,7 @@ While compaction reduces storage needs, Redpanda's compaction (just like Kafka's

== Configure a cleanup policy

A compaction policy may be applied to a cluster or to an individual topic. If both are set, the topic-level policy overrides the cluster-level policy. The cluster-level xref:reference:cluster-properties.adoc#log_cleanup_policy[`log_cleanup_policy`] and the topic-level xref:reference:topic-properties.adoc#cleanuppolicy[`cleanup.policy`] support the following three options:
A compaction policy may be applied to a cluster or to an individual topic. If both are set, the topic-level policy overrides the cluster-level policy. The cluster-level xref:reference:cluster-properties.adoc#log_cleanup_policy[`log_cleanup_policy`] and the topic-level xref:reference:topic-properties.adoc#cleanup-policy[`cleanup.policy`] support the following three options:

* `delete`: Records are deleted from the topic once the specified retention period (time and/or size allocations) is exceeded. This is the default mechanism and is analogous to disabling compaction.
* `compact`: This triggers only cleanup of records with multiple versions. A record that represents the only version for a given key is not deleted.
Expand Down Expand Up @@ -54,7 +54,7 @@ Where:
| Cluster
| The minimum ratio between the number of bytes in dirty segments and the total number of bytes in closed segments that must be reached before a partition's log is eligible for compaction in a compact topic.

| xref:reference:properties/topic-properties.adoc#mincleanabledirtyratio[`min.cleanable.dirty.ratio`]
| xref:reference:properties/topic-properties.adoc#min-cleanable-dirty-ratio[`min.cleanable.dirty.ratio`]
| Topic
| Topic-level override of the cluster-wide dirty ratio threshold.

Expand All @@ -70,11 +70,11 @@ Where:
| Cluster
| The minimum time in milliseconds that a message remains uncompacted in the log. Use to guarantee the minimum length of time that must pass after a message is written before it could be compacted. For example, to provide a lower bound on how long each message will remain in the (uncompacted) head.

| xref:reference:properties/topic-properties.adoc#maxcompactionlagms[`max.compaction.lag.ms`]
| xref:reference:properties/topic-properties.adoc#max-compaction-lag-ms[`max.compaction.lag.ms`]
| Topic
| The maximum amount of time in milliseconds that a message remains ineligible for compaction. Use to guarantee the maximum delay between the time a message is written and the time the message becomes eligible for compaction.

| xref:reference:properties/topic-properties.adoc#mincompactionlagms[`min.compaction.lag.ms`]
| xref:reference:properties/topic-properties.adoc#min-compaction-lag-ms[`min.compaction.lag.ms`]
| Topic
| The minimum time in milliseconds that a message remains uncompacted in the log. Use to guarantee the minimum length of time that must pass after a message is written before it could be compacted. For example, to provide a lower bound on how long each message will remain in the (uncompacted) head.
|===
Expand Down Expand Up @@ -106,7 +106,7 @@ Redpanda runs a scan every `log_compaction_interval_ms`. During each scan:

Compaction also enables deletion of existing records through tombstones. For example, as data is deleted from a source system, clients produce a tombstone record to the log. A tombstone contains a key and the value `null`. Tombstones signal to brokers and consumers that records with the same key prior to it in the log should be deleted.

You can specify how long Redpanda keeps these tombstones for compacted topics using both a cluster configuration property config_ref:tombstone_retention_ms,true,properties/cluster-properties[] and a topic configuration property xref:reference:properties/topic-properties.adoc#deleteretentionms[`delete.retention.ms`]. If both are set, the topic-level tombstone retention policy overrides the cluster-level policy.
You can specify how long Redpanda keeps these tombstones for compacted topics using both a cluster configuration property config_ref:tombstone_retention_ms,true,properties/cluster-properties[] and a topic configuration property xref:reference:properties/topic-properties.adoc#delete-retention-ms[`delete.retention.ms`]. If both are set, the topic-level tombstone retention policy overrides the cluster-level policy.

[NOTE]
====
Expand Down
Loading
Loading