From f0f923cbd5a9928ce03d5be50e8f74c78f1022d6 Mon Sep 17 00:00:00 2001
From: Cryptskii <47649969+cryptskii@users.noreply.github.com>
Date: Tue, 25 Aug 2026 17:06:33 -0400
Subject: [PATCH] =?UTF-8?q?fix(sdk):=20use=20as=5Fchunks=20in=20capsule=20?=
 =?UTF-8?q?counterparty=20decode=20=E2=80=94=20unbreaks=20CI=20on=20clippy?=
 =?UTF-8?q?=201.98?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

CI's Rust job failed with:

  error: using `chunks_exact` with a constant chunk size
    --> dsm_sdk/src/storage/client_db/recovery.rs:1092
    = note: `#[deny(clippy::chunks_exact_to_as_chunks)]` implied by `#[deny(warnings)]`

NOT a regression from any recent PR
-----------------------------------
The flagged line dates from the initial commit (1f60266c, 2026-03-19) and is
absent from the diff of the PR whose CI reported it. What changed is CI's
toolchain: `chunks_exact_to_as_chunks` is new in clippy 1.98, and dsm_sdk
denies warnings crate-wide (lib.rs:90). Main was going red on the next push
regardless of what merged.

The fix replaces the pattern rather than suppressing it. `as_chunks` yields
`&[u8; 32]` directly, so the scratch array and its copy_from_slice disappear:

  -    let mut ids = Vec::with_capacity(blob.len() / 32);
  -    for chunk in blob.chunks_exact(32) {
  -        let mut arr = [0u8; 32];
  -        arr.copy_from_slice(chunk);
  -        ids.push(arr);
  -    }
  -    Ok(ids)
  +    Ok(blob.as_chunks::<32>().0.to_vec())

The existing `blob.len() % 32 != 0` guard already rejects a remainder, so the
discarded `.1` is provably empty and behaviour is identical.

Why this was invisible locally
------------------------------
Local clippy is 0.1.96; CI's is 1.98.0. A lint that does not exist locally
cannot fire locally, so `make lint` green was SILENT about it rather than
clean. Compounding it, Homebrew's cargo shadows rustup's, so
`cargo clippy --version` reported 0.1.96 even under `rustup run stable`
(1.97.1).

Verified by reproducing the failure, not by assuming
----------------------------------------------------
Installed a pinned 1.98 toolchain (additive; the default stays 1.97.1) and
POSITIVE-CONTROLLED it against the pre-fix code — it reproduces the CI error
exactly. Local 1.97 emitted NOTHING on that line and would have "confirmed"
the fix while proving nothing.

CI aborts at the first error, so a single reported failure does not bound the
work: swept `cargo clippy --all-targets -- -D warnings` under 1.98 across the
whole workspace. Clean, exit 0 — recovery.rs was the only occurrence, and grep
confirms no constant-size `chunks_exact` remains.

Verification (three gates, each run separately with its own exit code)
  board            68 suites, 3811 passed, 0 failed, 19 ignored, exit 0
  make lint (1.96) exit 0, 0 errors
  clippy 1.98      --all-targets, exit 0, 0 errors
---
 .../dsm_sdk/src/storage/client_db/recovery.rs          | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/dsm_client/deterministic_state_machine/dsm_sdk/src/storage/client_db/recovery.rs b/dsm_client/deterministic_state_machine/dsm_sdk/src/storage/client_db/recovery.rs
index b167059c4..f475c64b2 100644
--- a/dsm_client/deterministic_state_machine/dsm_sdk/src/storage/client_db/recovery.rs
+++ b/dsm_client/deterministic_state_machine/dsm_sdk/src/storage/client_db/recovery.rs
@@ -1088,13 +1088,9 @@ pub fn get_capsule_counterparty_ids() -> Result<Vec<[u8; 32]>> {
             blob.len()
         ));
     }
-    let mut ids = Vec::with_capacity(blob.len() / 32);
-    for chunk in blob.chunks_exact(32) {
-        let mut arr = [0u8; 32];
-        arr.copy_from_slice(chunk);
-        ids.push(arr);
-    }
-    Ok(ids)
+    // `as_chunks` yields `&[u8; 32]` directly, so the length check above is the
+    // only remainder handling needed and the copy_from_slice dance goes away.
+    Ok(blob.as_chunks::<32>().0.to_vec())
 }
 
 /// Store the tombstone hash for the recovering device (our old device).