Repository navigation
id(discovery): resolve_config pairs a CLI topic/secret with the public default for the other half under --no-default-topic #4756
Description
Problem
id_core::discovery::resolve_config resolves the gossip topic and the topic secret independently, so with --no-default-topic and exactly one of --topic / --topic-secret given, the result pairs a CLI-provided value with the public network's hardcoded default for the other half:
--no-default-topic --topic my-private-net(no secret) → topicmy-private-net, secret =DEFAULT_TOPIC_SECRET(the public, in-source secretid-public-discovery-v1).--no-default-topic --topic-secret my-private-secret(no topic) → topic =DEFAULT_TOPIC(id-peer-discovery-v1, the public topic), secret = the CLI secret.
That contradicts resolve_config's own documented cascade (step 7, crates/id-core/src/discovery.rs:231-232): "If no_default_topic is true, drop the default topic and secret (keep only CLI-provided values; if none, fall back to hardcoded constants to avoid empty values)". The per-field fallback at discovery.rs:275-278 (topic) and discovery.rs:294-295 (secret) fires even when the other half was CLI-provided, so "skip the defaults" silently reintroduces one default.
Topic and secret are consumed as a pair at both call sites — TopicId::new(config.topic) together with RecordPublisher::new(..., config.topic_secret, ...) in pkgs/id/src/commands/serve.rs (~1239-1248) and pkgs/id/src/commands/peers.rs (~430-438) — and the secret is what encrypts the topic's DHT bootstrap records (DEFAULT_TOPIC_SECRET doc, discovery.rs:57-65: nodes with the same secret discover each other; the default is public knowledge). A "private" topic paired with the public secret is discoverable by anyone who knows the topic name; a private secret paired with the public topic name puts the node's records on the public topic under a secret nobody else shares.
Evidence (verified this run, laptop probe at origin/main f28aa79)
Probe test crates/id-core/tests/probe_resolve_pair.rs in a detached laptop worktree (~/git/fleet/probe-2026-11-02-laneB-scan4), run with cargo test -p id-core --test probe_resolve_pair:
resolve_config(&[], Some("my-private-net"), None, false, false, true)printedtopic="my-private-net"andsecret_is_public_default=true(secret bytes equalDEFAULT_TOPIC_SECRET).resolve_config(&[], None, Some("my-private-secret"), false, false, true)printedtopic="id-peer-discovery-v1"andsecret_is_cli=true.
Both assertions of pair-consistency failed, as expected from reading the two independent fallback chains.
Acceptance criteria
- With
no_default_topic = trueand exactly one ofcli_topic/cli_topic_secretprovided,resolve_confignever pairs it with the public hardcoded default for the other half: either the pair falls back together (both hardcoded) only when neither is provided, or resolution refuses/names the missing half — one behaviour, documented in the step-7 cascade text and matched by the code. - New unit tests cover both single-sided cases under
no_default_topic, plus the existing both-provided and neither-provided cases (test_resolve_config_no_default_topic*keep passing or are updated to the documented behaviour). - The non-
no_default_topiccascade (conf pair, per-field CLI override) is unchanged.
Found by new-issue-creator lane B (code) while scanning id-core modules not covered by lane A's recent passes (discovery.rs was not in its scan lists).
Activity
dezren39 commentedon Nov 3, 2026
🤖 Agent note · filed
dezren39 commentedon Nov 3, 2026
🤖 Agent note · handed off
OpenCode worker session bound and prompted for this already-claimed task.
dezren39 commentedon Nov 3, 2026
🤖 Agent note · handed_off
14 remaining items
dezren39 commentedon Nov 4, 2026
🤖 Agent note · handed off
dezren39 commentedon Nov 4, 2026
🤖 Agent note · handed off
dezren39 commentedon Nov 4, 2026
agent-note:v1
state: picked-up
queue: repo-health-code-pilot
task: 6754 (small_fix, worker repo-worker-code, lane ec118cad-0fd3-4652-91c4-27432f2f2efd)
by: openchamber-scheduled-lane
at: 2026-11-04T01:08Z
Fresh revalidation: issue #4756 is OPEN. Canonical PR #4763 is OPEN, linked, and says
Fixes #4756; fresh PR status is SUCCESS (2/2 checks), no unresolved review feedback, and mergeable state is clean. The PR is authored and assigned todezren39(the repository owner); the lane rule says never touch a Drew-owned PR, so I will not modify or merge it.action: escalating the ownership/merge decision to Drew; no code, branch, or PR changes.
labels: syncing issue labels to the claimed state, then blocking with
user/escalated.dezren39 commentedon Nov 4, 2026
agent-note:v1
state: blocked
queue: repo-health-code-pilot
task: 6754 (small_fix, worker repo-worker-code, lane ec118cad-0fd3-4652-91c4-27432f2f2efd)
by: openchamber-scheduled-lane
at: 2026-11-04T01:11Z
Verified: task is blocked as escalated-to-user. Issue #4756 remains OPEN. Canonical PR #4763 remains OPEN, is mergeable with checks SUCCESS (2/2) and no unresolved feedback, but GitHub identifies dezren39 as both author and assignee. The runbook forbids touching Drew-owned PRs. No PR changes were made.
Drew decision required: explicitly authorize this lane to shepherd or merge PR #4763 despite that restriction, or handle the merge directly. If authorized, revalidate PR state before acting.
labels: queue/blocked + status/blocked + user/escalated; claim labels removed.