Skip to content

fix(logging): add startup and shutdown lifecycle events#2359

Open
kkovaacs wants to merge 1 commit into
krisztian/log-lifetime-eventsfrom
krisztian/log-startup-shutdown-events
Open

fix(logging): add startup and shutdown lifecycle events#2359
kkovaacs wants to merge 1 commit into
krisztian/log-lifetime-eventsfrom
krisztian/log-startup-shutdown-events

Conversation

@kkovaacs

@kkovaacs kkovaacs commented Jul 20, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Log structured startup configuration and readiness events for the node, validator, NTX builder, and remote prover.
  • Report bootstrap start and completion, including genesis sources, commitments, configuration paths, and output directories.
  • Track full-node synchronization readiness and log state transitions without duplicate events.
  • Sanitize service endpoints before including them in startup logs.
  • Log SIGINT/SIGTERM shutdown requests and successful completion, while returning a non-zero exit code when graceful shutdown times out.

Partially resolves part 5 of issue #2330

Changelog

[[entry]]
scope       = "general"
impact      = "added"
description = "User visible log events have been added for startup and shutdown to all services."

if self.genesis_block_file.is_some() { "file" } else { "network" },
genesis.source = %self.genesis_block_file.as_ref().map_or_else(
|| self.network.map_or_else(
|| "unknown".to_owned(),

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: "undefined" or "custom" instead of "unknown"? Not important

@Mirko-von-Leipzig Mirko-von-Leipzig left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm unsure how I feel about this tbh. It achieves the goal, but I think we're wading into the territory of the telemetry and logging overshadowing the actual code that I want to see.

Or put differently, I want the majority of the LoC in a function to be actual logic. Not logging or helper functions for it.

Some of this is dictated by instrument! scoping for field recordings, but I feel this is going to be a problem no matter what given tracing API.

We can go ahead; I don't have a better solution.

Comment on lines +66 to +73
tracing::info!(
target: crate::LOG_TARGET,
{
genesis.commitment = %genesis_commitment,
data.directory = %self.data_directory.display(),
},
"Node bootstrap complete",
);

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if it would be beneficial to create our own macro; given that we don't want the full tracing feature set.

If we re-arrange the macro order, we can put the fields at the end and remove the need for { } encapsulation?

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.

3 participants