Repository navigation
Four replication config knobs are silently inert: env.get resolves only names registered in CONFIG_PARAMS #734
Description
Activity
Correction: six, not four. cb1kenobi audited every
env.get('replication_…')call site inreplicationConnection.tsagainst the registeredREPLICATION_*entries (on harper#2233) and found two more unregistered:read as default that always wins replication_subscriptionResolveTimeout60000 replication_pauseStallTimeoutderived from pingTimeout/blobTimeoutreplication_pauseStallTimeoutis the worst of the six: the comment above it explicitly tells operators to override it ("Override withreplication_pauseStallTimeoutfor clusters with extreme single-transaction sizes") and it does nothing. Verified againstcore/utility/hdbTerms.ts— neither name is present.So the full list is six. That audit pass is the one this issue asked for; folding it in here.
- added a commit that references this issue
on Sep 2, 2026 - added a commit that references this issue
on Sep 3, 2026 - added a commit that references this issue
on Sep 3, 2026 - added a commit that references this issue
on Sep 3, 2026 - added a commit that references this issue
on Oct 8, 2026 - added a commit that references this issue
on Oct 8, 2026
Metadata
Metadata
Assignees
Labels
Type
Fields
Priority
P1
env.get(name)→configUtils.getConfigValue(name)returnsundefinedfor any name absent fromCONFIG_PARAM_MAP(built fromCONFIG_PARAMSin coreutility/hdbTerms.ts). These four are read inreplication/replicationConnection.tsbut are not registered, so a value set inharperdb-config.yamlis silently ignored and the compiled-in default always applies:replication_receiveEventHighWaterMarkreplication_receiveYieldIntervalreplication_copyCheckpointRecordsreplication_copyCheckpointMaxIntervalMsConfirmed empirically: a newly added param behaved exactly this way (config value ignored, default
applied) until registered in
CONFIG_PARAMS— see harper-pro#733 and its companion core commit.This matters beyond tidiness: incident reports have described tuning attempts on
receiveEventHighWaterMarkand reasoned about it as an operator lever, when it cannot be changed atall. Registering them makes the config do what the code already implies, but it does mean a
previously-ignored value in someone's config file would start taking effect — so it deserves its own
review rather than riding along with a fix.
Also worth an audit pass: any other
env.get('...')call in harper-pro or core reading a name thatis not in
CONFIG_PARAMS.