You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Four replication config knobs are silently inert: env.get resolves only names registered in CONFIG_PARAMS #734
env.get(name) → configUtils.getConfigValue(name) returns undefined for any name absent from CONFIG_PARAM_MAP (built from CONFIG_PARAMS in core utility/hdbTerms.ts). These four are read in replication/replicationConnection.ts but are not registered, so a value set in harperdb-config.yaml is silently ignored and the compiled-in default always applies:
read as
default that always wins
replication_receiveEventHighWaterMark
100
replication_receiveYieldInterval
100
replication_copyCheckpointRecords
1000
replication_copyCheckpointMaxIntervalMs
5000
Confirmed 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 receiveEventHighWaterMark and reasoned about it as an operator lever, when it cannot be changed at
all. 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 that
is not in CONFIG_PARAMS.
Correction: six, not four. cb1kenobi audited every env.get('replication_…') call site in replicationConnection.ts against the registered REPLICATION_* entries (on harper#2233) and found two more unregistered:
read as
default that always wins
replication_subscriptionResolveTimeout
60000
replication_pauseStallTimeout
derived from pingTimeout/blobTimeout
replication_pauseStallTimeout is the worst of the six: the comment above it explicitly tells operators to override it ("Override with replication_pauseStallTimeout for clusters with extreme single-transaction sizes") and it does nothing. Verified against core/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.
Activity
kriszyp commentedon Aug 20, 2026
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:replication_subscriptionResolveTimeoutreplication_pauseStallTimeoutpingTimeout/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.
Retire silent exhausted budget entries, key structured record ids, gu…
Retire silent exhausted budget entries, key structured record ids, gu…
Bound a held source-503 blob gap across reconnects with an escalation…
Retire silent exhausted budget entries, key structured record ids, gu…
Register the config params Harper reads but never registered
Register the config params Harper reads but never registered