Skip to content

apollo_config,apollo_config_manager: stop re-logging the config load on every poll - #14932

Open
matanl-starkware wants to merge 1 commit into
mainfrom
matanl/config-quiet-repeated-load-logs
Open

apollo_config,apollo_config_manager: stop re-logging the config load on every poll#14932
matanl-starkware wants to merge 1 commit into
mainfrom
matanl/config-quiet-repeated-load-logs

Conversation

@matanl-starkware

Copy link
Copy Markdown
Collaborator

What

ConfigManagerRunner reloads the config on a timer. Each tick re-emitted three info! lines in every pod:

  • config_manager_runner.rs"ConfigManagerRunner: periodic check triggered, updating config"
  • loading.rs"Ignoring default values by overriding with an empty map."
  • loading.rs"Loading custom config file: ..." (once per file)

Now:

  • the two loading.rs lines report at info! for the first load of the process and trace! afterwards, via a CONFIG_LOADED_BEFORE atomic;
  • the tick heartbeat drops to trace!.

Why

Part of a round of log-cost reduction. Measured over 24h of Mainnet logs via Log Analytics, these three lines are ~9.8% of sequencer-gateway's log bytes and ~3% of sequencer-mempool's — roughly $60/month fleet-wide. They fire in every pod, forever, for a config that almost never changes.

update_config already compares old vs new and no-ops when nothing changed, but load_and_validate_config underneath it logged unconditionally.

Why not just debug!

Production runs RUST_LOG=debug,cairo_vm=warn, so demoting to debug! would save nothing. trace! is below the deployed threshold.

What's preserved

  • The startup config load still logs in full at info! — that is the occurrence anyone actually reads.
  • Real config changes are still reported by log_config_diff ("ConfigManagerRunner: {key} changed from {old} to {new}") and "Successfully updated dynamic config", both untouched.
  • The filesystem-watcher path ("file change detected") is untouched — it only fires on an actual change.
  • The flag is only set once a load runs to completion, so a first load that fails early still logs at info! on the next attempt.

Test plan

  • cargo build -p apollo_config -p apollo_config_manager
  • SEED=0 cargo test -p apollo_config — 34 passed, 0 failed
  • SEED=0 cargo test -p apollo_config_manager — 15 passed, 0 failed
  • scripts/rust_fmt.sh

🤖 Generated with Claude Code

…on every poll

The config manager reloads the config on a timer, and each reload re-emitted
the same three info lines in every pod: the periodic-check heartbeat, the
default-values notice, and one line per custom config file. On a config that
almost never changes, that is ~7% of sequencer-gateway's log bytes and ~3% of
sequencer-mempool's.

The startup load is the one worth reading, so the two loading.rs lines now
report at info for the first load of the process and at trace afterwards, and
the tick heartbeat drops to trace. An actual config change is still reported
by log_config_diff, which is untouched.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@cursor

cursor Bot commented Aug 9, 2026

Copy link
Copy Markdown

PR Summary

Low Risk
Logging-only change with no behavior to config loading, validation, or update logic; real config changes remain at info.

Overview
Cuts repeated info! noise from periodic config reloads while keeping the first load visible at info!.

In apollo_config, a process-wide CONFIG_LOADED_BEFORE flag and log_config_load route the “ignoring default values” and “loading custom config file” messages to trace! after the first successful load_and_process_config completion (the flag is set only at the end of that path, so a failed first attempt still logs at info! on retry).

In apollo_config_manager, the periodic poll heartbeat (“periodic check triggered, updating config”) moves from info! to trace!. File-change detection, log_config_diff, and “Successfully updated dynamic config” are unchanged.

Reviewed by Cursor Bugbot for commit 7f0051f. Bugbot is set up for automated code reviews on this repo. Configure here.

@reviewable-StarkWare

Copy link
Copy Markdown

This change is Reviewable

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants