Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

remove redundant/diverging hardcoded defaults in parseInt/parseLong wrapping ConfigKey reads

Aperta
#13,893 3 commenti 0 reazioni 1 assegnatario Vedi su GitHub

@DaanHoogland ci sta già lavorando.

Dal 18/8/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

type:technical-debt

Many call sites read a ConfigKey via the raw DAO and wrap the result in NumbersUtil.parseInt(value, someLiteral) / NumbersUtil.parseLong(...) / Integer.parseInt(...), supplying a hardcoded fallback even though the ConfigKey already carries its own default via .defaultValue() (and .value() applies that default automatically when no DB row exists). Most of the time the literal happens to match the ConfigKey's declared default, so it's just redundant. But it doesn't always match — which is a latent bug, not just noise, since the two numbers silently diverge depending on which code path executes.

Found during the .value() migration pass (issue #10752):

  • DeploymentPlanningManagerImpl.javaHostReservationReleasePeriod: ConfigKey default is "300000", but the field's Java-level initializer is 60L * 60L * 1000L (3,600,000), and the code only falls back to the ConfigKey default when the persisted value is <= 0 — not when the row is simply missing (null), in which case it silently keeps 3,600,000 instead of 300,000.
  • StorageCacheManagerImpl.javaExpungeWorkers: ConfigKey default is "1", but the read is NumbersUtil.parseInt(configDao.getValue(...), 10) — a hardcoded fallback of 10 vs. the registered default of 1.
  • UcsManagerImpl.javaUCSSyncBladeInterval: ConfigKey default is "3600", but a leftover catch (NumberFormatException e) { syncBladeInterval = 600; } uses 600. Low risk in practice since .value() no longer throws on parse, but the mismatched literal is still latent debt.

These three were left un-migrated to .value() specifically because of this discrepancy — picking either number without a decision would silently change fresh-install/edge-case behavior. Worth a repo-wide sweep for the same parseInt/parseLong-with-hardcoded-default pattern, since these three were only found incidentally while migrating unrelated call sites, not through an exhaustive search.

Lingua principale
Java
Stelle
3.1k
Fork
1.4k
Merge medio
6g 20h
PR unite (30g)
27

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di apache/cloudstack

Tutte le issue di apache/cloudstack

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.