Summary
Setting an Integer-typed configuration property (e.g. HttpPortNumber, ServerPortNumber) to a non-numeric value is silently accepted: the command prints Updated configuration '<name>' as if it succeeded, but the underlying field is left completely unchanged. No warning or error is surfaced, so a typo or bad script silently produces a no-op that looks like a successful change.
Steps to reproduce
mxcli new MxTestRepro --version 11.12.0 --skip-init
cd MxTestRepro
./mxcli -c "ALTER SETTINGS CONFIGURATION 'Default' HttpPortNumber = ''" -p MxTestRepro.mpr
# Output: "Updated configuration 'Default'" -- implies success
./mxcli -c "DESCRIBE SETTINGS" -p MxTestRepro.mpr
# HttpPortNumber is still 0 (or whatever it was before) -- nothing was actually changed
Root cause
mdl/executor/cmd_settings.go:
case "HttpPortNumber":
if v, err := strconv.Atoi(valStr); err == nil {
cfg.HttpPortNumber = v
}
case "ServerPortNumber":
if v, err := strconv.Atoi(valStr); err == nil {
cfg.ServerPortNumber = v
}
The strconv.Atoi error is silently discarded (if err == nil), so an invalid value just skips the assignment. Since the caller always prints a success message afterward regardless of which fields actually changed, this produces a misleading "successful" no-op.
Suggested fix
Return a validation error instead of silently ignoring the parse failure, e.g.:
case "HttpPortNumber":
v, err := strconv.Atoi(valStr)
if err != nil {
return mdlerrors.NewValidation(fmt.Sprintf("HttpPortNumber must be an integer, got %q", valStr))
}
cfg.HttpPortNumber = v
(same pattern for ServerPortNumber, and worth checking whether other typed configuration settings have the same silent-swallow pattern elsewhere in this file).
Environment
- mxcli: built from
main @ ead892672f82fdc5f54ed8a944e98026845700a2 (2026-07-28)
- Mendix version: 11.12.0
- Reproduced on a throwaway blank project, not a production project
Summary
Setting an Integer-typed configuration property (e.g.
HttpPortNumber,ServerPortNumber) to a non-numeric value is silently accepted: the command printsUpdated configuration '<name>'as if it succeeded, but the underlying field is left completely unchanged. No warning or error is surfaced, so a typo or bad script silently produces a no-op that looks like a successful change.Steps to reproduce
Root cause
mdl/executor/cmd_settings.go:The
strconv.Atoierror is silently discarded (if err == nil), so an invalid value just skips the assignment. Since the caller always prints a success message afterward regardless of which fields actually changed, this produces a misleading "successful" no-op.Suggested fix
Return a validation error instead of silently ignoring the parse failure, e.g.:
(same pattern for
ServerPortNumber, and worth checking whether other typed configuration settings have the same silent-swallow pattern elsewhere in this file).Environment
main@ead892672f82fdc5f54ed8a944e98026845700a2(2026-07-28)