What issue are you seeing?
config/value/write appears to treat JSON null as a clear/unset operation, but clearing a missing nested config value currently fails when an intermediate parent table is absent.
For example, clearing features.personality from an empty config.toml returns configPathNotFound / Path not found because the [features] table does not exist.
This makes reset/clear flows brittle for app-server clients, since a client has to distinguish between “value exists” and “value is already absent” before sending an otherwise idempotent clear.
What steps can reproduce the bug?
Start with an empty user config.toml.
Call config/value/write with:
{
"keyPath": "features.personality",
"value": null,
"mergeStrategy": "replace"
}
Actual result:
configPathNotFound / Path not found
I reproduced this locally with a focused regression test against ConfigManager::write_value: clearing features.personality from an empty config fails before the fix because the missing features parent table is treated as a path-not-found error.
What is the expected behavior?
Clearing an already-unset nested config value should succeed as an idempotent no-op.
The response should be successful, the config file should remain unchanged, and config/value/write should not return configPathNotFound just because the parent table is absent.
Additional information
I searched for existing issues/PRs using terms such as config/value/write, configPathNotFound, ConfigPathNotFound, features.personality, null, and clear missing nested config path, and I did not find an exact duplicate.
Related but different issues I found include #10499 and #11728, but those appear to cover different config-write failure modes.
I have a small regression test and narrow fix direction prepared if maintainers agree this should be treated as a no-op.
What issue are you seeing?
config/value/writeappears to treat JSONnullas a clear/unset operation, but clearing a missing nested config value currently fails when an intermediate parent table is absent.For example, clearing
features.personalityfrom an emptyconfig.tomlreturnsconfigPathNotFound/Path not foundbecause the[features]table does not exist.This makes reset/clear flows brittle for app-server clients, since a client has to distinguish between “value exists” and “value is already absent” before sending an otherwise idempotent clear.
What steps can reproduce the bug?
Start with an empty user
config.toml.Call
config/value/writewith:{ "keyPath": "features.personality", "value": null, "mergeStrategy": "replace" }Actual result:
I reproduced this locally with a focused regression test against
ConfigManager::write_value: clearingfeatures.personalityfrom an empty config fails before the fix because the missingfeaturesparent table is treated as a path-not-found error.What is the expected behavior?
Clearing an already-unset nested config value should succeed as an idempotent no-op.
The response should be successful, the config file should remain unchanged, and
config/value/writeshould not returnconfigPathNotFoundjust because the parent table is absent.Additional information
I searched for existing issues/PRs using terms such as
config/value/write,configPathNotFound,ConfigPathNotFound,features.personality,null, andclear missing nested config path, and I did not find an exact duplicate.Related but different issues I found include #10499 and #11728, but those appear to cover different config-write failure modes.
I have a small regression test and narrow fix direction prepared if maintainers agree this should be treated as a no-op.