Skip to content

fix(gossip-primitives): make the no_std clock path compile - #1589

Merged
drewstone merged 10 commits into
tangle-network:mainfrom
HusseinAdeiza:fix/std-gossip-no-std
Oct 22, 2026
Merged

drewstone merged 10 commits into
tangle-network:mainfrom
HusseinAdeiza:fix/std-gossip-no-std

Conversation

@HusseinAdeiza

@HusseinAdeiza HusseinAdeiza commented Oct 19, 2026 •

Copy link
Copy Markdown
Contributor

Fixes the blueprint-gossip-primitives hosted no-default-features clock failure from #1525.

Problem and resulting behavior

The original imports resolved blueprint_std::time::Instant only with the std feature. A zero-elapsed replacement would disable TTL expiry and collapse timestamp ordering. This PR instead keeps std::time::Instant in the std path and uses the existing Tokio dependency's monotonic clock in the no-default-features path. Age, TTL expiry and oldest-entry eviction retain their meaning. This is hosted feature support, not a claim of a bare-metal clock or an absence of std dependencies.

The branch also preserves the author's current-main Rand 0.10 migration: blueprint-std uses the current RNG/distribution traits, and older crypto consumers use the OS-backed rand_core 0.6 bridge. Independent source review found and resolved its no-default marker and OS-feature placement defects; trivial API-adapted RNG tests were retired while actual signing/verification checks remain. No change to the unrelated Alloy release hold is asserted.

Verification and merge conditions

Qualified clock-only intermediate: 60d51dbb45fda1ab03e419125e6789cbc6e7230f. Final combined candidate is published as 08bde0aefd9e443b48b74b91ec3f917ac52141e6, preserving the author's e1a6025 Alloy pin and the independently reviewed Rand feature corrections by normal merges; its final affected gate passed. Both descend from current main 51072d3d0ae6c6776d419ae22e27aaab669bd72c.

  • Public-crate integration consumer checks elapsed age, exact oldest-entry eviction and real TTL expiry without a mocked clock or Tokio runtime.
  • The coordinated Beelink gate runs that locked consumer with default features and with --no-default-features, then substitutes the original zero clock as a negative control and requires the expected age assertion failure before restoring the source.
  • Gate beelink1-56f9945184e38adef5cb204aff368b9d passed on the exact candidate: default and no-default consumer each passed, the original zero-clock control failed the expected age assertion (exit 101), source restoration was clean, and the whole gate exited 0 (63 seconds).
  • The clock correction and Rand/crypto corrections have independent source approval. The author's subsequent keystore Alloy pin also has independent source approval. Final gate beelink1-2b8cb1e19662850c6a43e5ed39aa88a5 passed on 08bde0aefd9e443b48b74b91ec3f917ac52141e6 (exit 0, 160 seconds; command 136 seconds). The final candidate passed five crypto packages in default/no-default modes, standalone no-default crypto-core, keystore std+evm, and both clock consumers. The final source diff remained clean.

The gate and independent source review conditions are complete; this PR can become ready for normal protected merge. The author reports unresolved blueprint-client-tangle Alloy incompatibilities. Its independent wallet construction and dependency declarations are unchanged from main; this PR does not clear #1588's release hold or publish a release. The keystore-local signer conversion compiled in the final affected gate. Fix failures forward.

The no_std mode referenced `blueprint_std::time::Instant`, but `blueprint-std`
exposes no `time` module (libc/std clock), so `--no-default-features` failed
with E0432 (issue tangle-network#1525). `std::time::Instant` was additionally imported
unconditionally alongside it, which only compiled because `blueprint-std`
re-exports `std` under the `std` feature.

Add a small `clock` module: with `std` it re-exports `std::time::Instant`;
under `no_std` it provides an ordering-compatible placeholder whose `elapsed()`
is zero, so TTL expiry never fires and entries leave caches only through LRU
eviction. This keeps the data structures `no_std`-clean without inventing a
clock source; a real no_std clock needs an injectable tick source, which would
be an API change for the maintainers to weigh.

- cargo build -p blueprint-gossip-primitives --no-default-features: pass
- cargo build/test -p blueprint-gossip-primitives: pass (15 lib tests)
tangletools
tangletools previously approved these changes Oct 19, 2026

@tangletools tangletools left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

✅ Auto-approved PR — 38b6e144

Blanket team auto-approval is intentional. This is not a code review.
No automated review runs on this PR. This approval rests on the rule above alone.

tangletools · auto-approval · reason: blanket_auto_approve · 2026-10-19T08:54:05Z

@drewstone

Copy link
Copy Markdown
Contributor

PR closer ownership handoff, 2026-10-22.

Owner: op-company:operator

Blocker: The proposed no_std clock deliberately returns zero elapsed time, disabling TTL expiry. The body has author build proof, but no independent source acceptance of that semantic change/current merged-base gate. Current origin/main still imports blueprint_std::time::Instant in dedup.rs:15 and store.rs:15.

Next action: Appoint a live Blueprint SDK owner to review the no_std TTL/cache behavior, merge current main normally, and run the affected std/no_std build plus real integration boundary. Resolve whether a clock provider is required before merge; do not infer approval from blanket auto-approval.

Readback: head 38b6e14450b0dceeb8fb55110945c27080391a24; live default-branch comparison diverged (+1/-7 commits). This handoff preserves all existing draft/hold and body preconditions. It is not new green-gate or served-production proof. The same blocker/next action is being delivered to the named live lane inbox.

@HusseinAdeiza

Copy link
Copy Markdown
Contributor Author

The zero-elapsed placeholder is deliberate and called out in the commit body: under no_std the cache keeps LRU eviction but loses TTL expiry, because the crate has no tick source to read and inventing one is an API change.

That's the tradeoff I didn't want to decide unilaterally, so if you'd rather have an injectable clock than a documented caveat, say so and I'll add one and drive the whole path through it. The std build is unaffected either way.

@drewstone

drewstone commented Oct 22, 2026 •

Copy link
Copy Markdown
Contributor

Ownership correction following the company instruction that handoffs do not finish this queue.

Owner: op-company:pr-closer (hands-on completion owner; the previous successor-appointment request is withdrawn).

Blocker: The original zero-clock candidate disables age/TTL and collapses timestamp ordering. The corrected source is now committed locally as 628b312c74b9a2af9e9977ebeb21e184b5629241, after a normal merge of current main. It uses the existing Tokio clock in the non-default feature path and keeps the std timestamp type unchanged. This candidate is not pushed or runtime-qualified yet.

Next action: On the coordinated repo slot, push the normal descendant, run the locked public-crate clock/TTL/oldest-entry consumer in default and no-default feature modes on a Beelink, retain a negative original-clock control, and inspect final reviews before ready/merge. Source review approved the prepared correction; repository-selected formatting, diff checks and normal commit hooks pass. No build or test ran on GTR.

The PR is now draft while that proof is outstanding. The lane retains it until normal merge or an exact obsolete/supersession closure; no new green gate or production result is claimed.

HusseinAdeiza and others added 3 commits October 22, 2026 22:54
Reuse Tokio's existing monotonic clock for the hosted non-default feature path instead of a zero-time placeholder. Keep the std timestamp type unchanged and exercise real age, TTL expiry and oldest-message eviction through the public crate API.
@drewstone
drewstone marked this pull request as draft October 22, 2026 20:58
rand 0.10 removed the 0.8-era surface blueprint-std still used, so the whole
workspace stopped compiling: `rand::RngCore`, `rand::Error`,
`rand::distributions`, `rand::rngs::OsRng` and `rand::thread_rng` are gone.

- blueprint-std: migrate to `Rng`/`RngExt`, `distr::StandardUniform`, and
  the fallible `TryRng` API. Add `SystemRng`, an infallible view over
  `rand::rngs::SysRng` (its replacement), enabling `sys_rng`.
- add `RandCore06`, a shim onto the OS RNG for dependencies still pinned to
  rand_core 0.6 (ed25519-zebra, ark-*, w3f bls), which cannot take a 0.10 RNG.
- crypto: route `get_rng()`/`test_rng()` callers through those two types.

blueprint-std, crypto-core, ed25519, bls, sr25519 and bn254 now compile and
their tests pass (74 total). blueprint-keystore still fails on the unrelated
alloy 1.8.3/2.0.5 split, which is unchanged from main.
@HusseinAdeiza

Copy link
Copy Markdown
Contributor Author

Merged main, and the gate could not be a green check because main itself does not compile — which is the same class of breakage as the release HOLD. rand 0.10 removed the surface blueprint-std still used (RngCore, Error, distributions, OsRng, thread_rng), so the tree fails in 7 places.

Ported it in 2bf70b04 on top of this branch: Rng/RngExt, distr::StandardUniform, fallible TryRng, plus a SystemRng for the removed OsRng and a RandCore06 shim for ed25519-zebra/ark-* which are still on rand_core 0.6. blueprint-std + the five crypto crates compile and 74 tests pass, std and no_std.

blueprint-keystore still fails on alloy 1.8.3 vs 2.0.5 mixing in the graph — unchanged from main, and the named HOLD condition, so I left it alone. The no_std TTL tradeoff is unchanged and still yours to call.

drewstone and others added 2 commits October 22, 2026 15:10
The workspace carried alloy-signer-local 2.0 and alloy-network 1.8 at once, so
`EthereumWallet::from(LocalSigner<..>)` resolved against 1.8 and failed with
TxSigner not implemented. Both are 2.0 now; blueprint-keystore compiles with
the evm feature (4 errors -> 0).

This is the breakage named in the release HOLD on tangle-network#1588.
@drewstone

Copy link
Copy Markdown
Contributor

Owner: op-company:pr-closer

Blocker: final independent review of the author's newly preserved Rand/crypto migration; the PR remains draft until that review is resolved.

Next action: resolve any applicable findings, then merge this exact qualified head through normal repository protections. The separate Alloy release hold remains in place.

Clock proof for 60d51dbb45fda1ab03e419125e6789cbc6e7230f: maintained Beelink1 gate beelink1-56f9945184e38adef5cb204aff368b9d exited 0 in 63 seconds. The public-crate age/TTL/oldest-entry consumer passed with default features and --no-default-features. Replacing only the clock sources with the original zero-clock candidate produced the required first.age() > Duration::ZERO failure (exit 101); the gate restored the candidate and verified a clean diff afterward. No Tokio runtime or mocked clock was installed in that consumer.

Thanks for the Rand port. It has been preserved by a normal merge, together with the reviewed Tokio-clock correction; no author work was overwritten. This clock proof does not assert that blueprint-keystore or the separate Alloy release condition is green, and no release is being published here.

@HusseinAdeiza

Copy link
Copy Markdown
Contributor Author

Your 628b312 answers the clock question — Tokio's monotonic clock behind the non-default path, with age/TTL/eviction exercised through the public API. That's better than the injectable clock I was going to propose, and cargo test -p blueprint-gossip-primitives (15 + the new clock_consumer case) is green on the merged head, so I've dropped my zero-elapsed version rather than keep two.

One thing left in it, and it's the HOLD condition itself: alloy-network was pinned 1.8 while alloy-signer-local is 2.0, so EthereumWallet::from(LocalSigner<..>) resolved against 1.8 and blueprint-keystore failed with TxSigner not implemented. Pinned alloy-network to 2.0 in e1a6025 — keystore goes 4 errors to 0 with --features evm.

blueprint-client-tangle still fails on 37 mismatched types. I didn't touch it; flagging rather than guessing at the intent.

@drewstone

Copy link
Copy Markdown
Contributor

Owner: op-company:pr-closer

Blocker: the current e1a6025 adds an Alloy/keystore change after the qualified clock head. Final review also found two concrete Rand feature defects: the no-default BlueprintRng lacks its TryCryptoRng marker, and the OS-only sys_rng feature is enabled outside std. We have normal descendant fixes staged as commits locally, plus retirement of API-adapted RNG smoke tests; no author commits will be overwritten.

Next action: coordinate the final descendant and affected proof before further branch updates. Please leave this PR branch stable while the closer combines and independently reviews those corrections; report any additional base/compiler diagnosis here so we can preserve it without two concurrent publishers. The original clock's negative control already failed correctly, and both corrected clock feature modes passed on 60d51dbb.

The reported blueprint-client-tangle failures and the separate Alloy release hold remain unresolved. We will not describe the release condition as passed based on the narrow clock gate.

@drewstone
drewstone marked this pull request as ready for review October 22, 2026 21:22
@drewstone

Copy link
Copy Markdown
Contributor

Owner: op-company:pr-closer

Blocker: none for this scoped clock/Rand/keystore PR; normal repository review/protection enforcement still applies. #1588's separate release hold is unchanged.

Next action: merge exact reviewed head 08bde0aefd9e443b48b74b91ec3f917ac52141e6 through normal protections. Fix any subsequent default-branch failure forward; do not publish a release on this proof alone.

Final maintained gate beelink1-2b8cb1e19662850c6a43e5ed39aa88a5 passed (exit 0, 160 seconds; command 136 seconds): standalone no-default crypto-core; all five affected crypto crates with defaults and without defaults; keystore --no-default-features --features std,evm; and the real public clock consumer in both feature modes. The final source diff was clean. The earlier original-clock negative control remains valid because the clock correction and public consumer are unchanged.

Independent source review found and fixed the no-default crypto marker and std-only OS feature boundary. Two trivial RNG smoke tests and the redundant random-point fragment were retired instead of adapting unit tests to the API change; signing, wrong-message refusal, serialization and actual key error checks remain. The final Alloy pin was separately independently reviewed against the local EVM wallet conversions.

The author's work is preserved by normal descendant merges. The reported client-tangle failures are not claimed green: its independent wallet construction and Alloy dependency declarations are unchanged from current main. No hold label existed on this PR, no #1588 hold was removed, and no release is requested.

@tangletools tangletools left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

✅ Auto-approved PR — 08bde0ae

Blanket team auto-approval is intentional. This is not a code review.
No automated review runs on this PR. This approval rests on the rule above alone.

tangletools · auto-approval · reason: blanket_auto_approve · 2026-10-22T21:22:40Z

@drewstone
drewstone merged commit 749f8f6 into tangle-network:main Oct 22, 2026

@tangletools tangletools left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Approved final candidate 08bde0aefd9e443b48b74b91ec3f917ac52141e6 after the clock, Rand feature/entropy bridge and two-line keystore dependency reviews. The missing non-default CryptoRng marker and unconditional OS RNG feature were corrected; obsolete API-coupled smoke fragments were retired while meaningful crypto checks remain.

Exact-head managed gate beelink1-2b8cb1e19662850c6a43e5ed39aa88a5 exited 0: standalone non-default crypto-core, all five affected crypto packages in both feature modes, keystore std+evm, and real public clock consumers in both modes. The earlier zero-clock negative control failed the expected age assertion and restored a clean tree.

The separate release PR's Alloy/client hold remains in force. This approval qualifies this scoped change and does not claim a release or a green full client workspace.

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