Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e18b7c1fc0
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| }); | ||
| peers_mtu_guard_ = adnl::PeersMtuGuard{sender, local_id_, std::move(peers), mtu}; | ||
| // Permanent members (over validator overlays, essentially the validator set) are trusted. | ||
| peers_mtu_guard_ = adnl::PeersMtuGuard{sender, local_id_, std::move(peers), mtu, /* trusted = */ true}; |
There was a problem hiding this comment.
Register permanent peers on the QUIC sender
When an overlay configures both transports, this trusted guard is installed only on the sender selected above, which prefers twostep_broadcast_sender_. The fast-sync overlay does exactly that—legacy ADNL for two-step and QUIC for Plumtree in validator/full-node-fast-sync-overlays.cpp—so its permanent validator peers are never marked trusted in the QUIC sender; their ready QUIC connections are consequently exported as trust="untrusted". Install the permanent-peer trust registration on the Plumtree sender as well when it is distinct.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7c7b0d8364
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| auto max_by_type = [&](Context family, auto value) { | ||
| family.open_family("gauge"); | ||
| for (const auto &[name, stat] : stats) { | ||
| family.with_label("type", name).with_label("window", "10m").push(value(stat)); |
There was a problem hiding this comment.
Derive the advertised max window from the calibrated tick rate
On x86 hosts whose invariant TSC is not 2 GHz, avoid labeling these samples as window="10m": ActorMetrics explicitly calibrates the real tick rate, but ActorTypeStatImpl::MaxCounter still divides ticks by the hard-coded 2 GHz Clocks::rdtsc_frequency() when rotating its 600-second buckets. For example, at 3 GHz the documented 10–20 minute retention becomes roughly 6.7–13.3 minutes, so slow actor spikes disappear from these dashboards materially earlier than operators are told; bucket rotation should use an actual time source/calibrated frequency, or the exposed window must reflect the real duration.
Useful? React with 👍 / 👎.
No description provided.