DaanHoogland commented on issue #13893:
URL: https://github.com/apache/cloudstack/issues/13893#issuecomment-5314995884
Worth calling out explicitly: the `ApiRateLimitServiceImpl` case noted above
is actually a *third* structural shape of this same divergent-default risk,
alongside the issue's original `parseInt`/`parseLong`-wrapping shape and the
raw-config-map shape from #13898:
- **parseInt/parseLong wrapping** (this issue's original scope):
`NumbersUtil.parseInt(configDao.getValue(key.key()), literalDefault)` — the
literal fallback silently diverges from the ConfigKey's registered default.
- **raw map / getValue with no fallback at all**: e.g.
`EventPurgeDelay`/`EventPurgeInterval` — the field simply keeps whatever it was
already initialized to when the row is missing.
- **if-null-skip** (the `ApiRateLimitServiceImpl` shape): `if (raw != null)
{ field = parse(raw); }` with no `else` — functionally identical to the
previous shape (field keeps its own hardcoded default when unset) but written
as a guarded assignment rather than a wrapped parse call, so it doesn't show up
in a grep for `parseInt`/`parseLong`.
All three converge on the same root cause (a raw retrieval path that never
consults `ConfigKey.defaultValue()`), but need different greps to find, which
is why a repo-wide sweep should probably search for all three shapes rather
than just the `parseInt`/`parseLong` one this issue was originally filed
against.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
