Open Masqueey opened 2 weeks ago
Hi Masqueey! 👋
Welcome, and thank you for opening your first issue in the repo!
Please wait for triaging by our maintainers.
As development is carried out in our spare time, you can support us by sponsoring our activities or even funding the development of specific issues. Sponsorship link
If you plan to raise a PR for this issue, please take a look at our contributing guide.
Thank you, @Masqueey, for your contribution! It appears that the default configuration property for log.msk.disable.policy via the API is set to "Delete," whereas for the manual method (could you clarify what that entails?), it’s set to "None." Would you mind sharing more details on this?
Thanks for your fast reply!
With "the manual method" I mean using our own api to copy the config, delete the topic, then create a topic with the same name and same (copied) config. Then the topic is usable again. (I assumed the "recreate topic" button in the UI did something similar.)
The default configuration property for log.msk.disable.policy via the API is set to "Delete," whereas for the manual method, it’s set to "None."
I noticed this too, however it is not an issue before I use the "recreate topic" button. The setting also remains "None" after the topic has been recreated. Updating it to something else after the recreation is not possible.
We could, of course, update our own API to set log.msk.disable.policy
to 'Delete' when it is included, but even then, why would this only be an issue after recreating it? On top of that, most of our topics have this setting currently on None
, so this would only be relevant for future topics.
To maybe aid in debugging this further, I now created a topic through the UI, noticed the remote.log.msk.disable.policy
setting was already set to None, even when not explicitly added in Custom Parameters in the creation process. (Could be some AWS or MSK setting? Not sure how to check that.)
But also here, if you recreate it with the recreate button, it freezes the settings due to the above setting being None. (According to the error.)
What I tried to test here was whether this was caused by first creating the topic through a different API and then recreating it through the KafkaUI. But turns out that even when (re)creating it through the UI, the setting is set to None automatically if not set explicitly to something else.
I'm having a similar issue. I cannot edit delete.retention.ms
on a compacted log topic. Which is strange, because it's a setting specifically for compacted logs.
Edit: it works if I type the whole name, but selecting is disabled.
Issue submitter TODO list
main
-labeled docker image and the issue still persists thereDescribe the bug (actual behavior)
After recreating a topic, its configuration settings get frozen. The error that is shown when trying to update the settings is not relevant in this case and other topics with the same config can still be updated.
Related FE issue: when settings are not frozen, they are grayed out and not clickable, but work when manually typed. When they can no longer be updated, they are black and clickable.
Expected behavior
After recreating a topic, its settings remain as configurable as before recreating it.
The FE part should be inverted, gray and not clickable when frozen, black and clickable when configurable.
Your installation details
Doubt it's relevant but some config:
Steps to reproduce
delete.retention.ms
> Notice it is grayed out and not clickable.)delete.retention.ms
> add a '0' to the end.Screenshots
No response
Logs
Additional context
remote.log.msk.disable.policy
configuration asDelete
whereas the setting on the topic is set toNone