I see the discussion now. So there is nothing wrong with the process. Adding an option to configure this behavior is acceptable as a quick solution to me as well.
Thanks, Yunze On Tue, Apr 22, 2025 at 9:15 PM Lari Hotari <lhot...@apache.org> wrote: > > There is a thread about cherry-picking the changes: > https://lists.apache.org/thread/g1jq0vkq0wt28mdnbg63bpw8fpx9ml42 > > Similar changes have also been made in the past to maintenance branches, so > this is not anything exceptional to bring up for discussion and then > cherry-pick to maintenance branches. > > > I propose to revert that PR. At least, we should add a broker level > > config or namespace level policy to control the behavior. But still, > > we definitely need a PIP for such changes. We need a further > > discussion for the compatibility issue rather than merging it and > > cherry-picking it into old branches. So I suggest reverting it first. > > Since there's a reason to have PR 24118 & PR 24154 changes in maintenance > branches, I'd suggest adding a way to configure this behavior. Adding a PIP > would be a good way to document this change. > > -Lari > > On 2025/04/22 12:50:13 Yunze Xu wrote: > > Hi all, > > > > https://github.com/apache/pulsar/pull/24118 introduces breaking > > changes on the downstream applications without a PIP. > > > > For example, our internal Kafka protocol implementations heavily rely > > on the behavior that partitions can be produced or consumed even if > > the partition metadata is deleted. Many tests failed due to this > > change. > > > > I didn't look into the technical details at the moment. But it should > > be noted that sometimes it's valid to read a partition without > > assuming the topic's partition metadata exists. > > > > I propose to revert that PR. At least, we should add a broker level > > config or namespace level policy to control the behavior. But still, > > we definitely need a PIP for such changes. We need a further > > discussion for the compatibility issue rather than merging it and > > cherry-picking it into old branches. So I suggest reverting it first. > > > > Please note that this PR also modifies many existing tests in Pulsar. > > It's a clear signal that breaking changes were made. We should be > > careful of such PRs. > > > > Thanks, > > Yunze > >
