-
Notifications
You must be signed in to change notification settings - Fork 3.7k
Description
Problem Description
When setting autoTopicCreation on namespace policy, the API validation prevents setting defaultNumPartitions when the topic type is non-partitioned. This limitation makes the API harder to use and less flexible.
Current behavior:
- Setting
defaultNumPartitionswithtopicType="non-partitioned"results in a validation error:"[defaultNumPartitions] is not allowed to be set when the type is non-partition."
Code location:
Lines 54 to 59 in 53162ff
| } else if (TopicType.NON_PARTITIONED.toString().equals(override.getTopicType())) { | |
| if (override.getDefaultNumPartitions() != null) { | |
| return ValidateResult.fail("[defaultNumPartitions] is not allowed to be" | |
| + " set when the type is non-partition."); | |
| } | |
| } |
Use Cases Affected
-
Configuration management: Users managing configurations programmatically or via infrastructure-as-code tools may want to set a default value even for non-partitioned topics, especially if they plan to switch to partitioned topics later.
-
API consistency: The validation requires users to conditionally include/exclude the
defaultNumPartitionsfield based on topic type, making the API less consistent and more error-prone. -
Configuration templates: Shared configuration templates or defaults become harder to maintain when they need to conditionally exclude fields.
Proposed Solution
Consider relaxing this validation to allow defaultNumPartitions to be set (but ignored) when topicType="non-partitioned". This would:
- Make the API more user-friendly
- Allow for more flexible configuration management
- Maintain backward compatibility (non-partitioned topics would still be created correctly)
- Simplify client code that doesn't need to conditionally set fields
Alternatively, if there's a technical reason this field must not be set, it would be helpful to document this clearly and potentially provide a clearer error message explaining why.
Question
Is this limitation necessary from a technical standpoint, or could it be relaxed to improve API usability?
Environment
- Pulsar version: 3.x, 4.x
- Component: Admin API / Namespace Policy