docs: fix misleading shadow linking troubleshooting check (DOC-2231)#1802
docs: fix misleading shadow linking troubleshooting check (DOC-2231)#1802JakeSCahill wants to merge 1 commit into
Conversation
…adow cluster The prerequisites already state that only the shadow cluster needs enable_shadow_linking, but the troubleshooting section told users to verify it on both clusters. LLM assistants latch onto this as a debugging gotcha even when irrelevant (DOC-2231).
✅ Deploy Preview for redpanda-docs-preview ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughUpdates Helm troubleshooting guidance for shadow linking. The documentation now states that Estimated code review effort: 1 (Trivial) | ~2 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
The troubleshooting section on k-shadow-linking told users to verify
enable_shadow_linkingon both clusters, but only the shadow (target) cluster requires it — the prerequisites partial on the same page already says so. The mismatch misleads readers and LLM assistants using the Docs MCP treat it as a debugging gotcha even when irrelevant (DOC-2231).Now the check targets the shadow cluster only, with a sentence explaining that the source cluster needs the property only when it also acts as the shadow cluster of another link (bi-directional topologies).
Beta counterpart PR follows. Fixes DOC-2231.