Clear 3 tsc -b errors from the #359 merge — clean npm run build is red on main #870

Merged

Brouie merged 1 commit from qa/359-tsc-signing-types into main

2026-06-12 07:54:42 +00:00

Brouie commented

2026-06-12 04:51:30 +00:00

(Migrated from gitlab.com)

A clean npm run build (fresh .tsbuildinfo, i.e. what CI / a fresh checkout gets) fails on main at 8408689 with 3 type-only errors. The #359 merge (cd17813, !867) added terraTxHash.ts and terraWalletSignTxRaw.ts, which carry them; an incremental build with a warm cache masks all three, which is why it slipped past the merge and my own earlier build check.

typescript@5.9.3 and @types/node@22.19.15 are both lockfile-pinned, so this is exactly what CI hits — not a local float.

The errors (all type-only, runtime is correct):

terraTxHash.ts:6 — txRaw.toBinary() returns Uint8Array<ArrayBufferLike>; crypto.subtle.digest wants BufferSource under the TS 5.9 lib. Asserted as BufferSource.
terraWalletSignTxRaw.ts:109 — the dev MnemonicWallet sets id 'mnemonic', which is outside the cosmes WalletName enum, so w.id === 'mnemonic' was a no-overlap comparison. Compared as string (preserves the check).
terraWalletSignTxRaw.ts:116 — ConnectedWallet.sequence is private, blocking wallet as { sequence?: bigint }. Routed through as unknown as.

No behavior change. Clean npm run build green after; full vitest 594/596 (the 2 fails are the known terraExplorer 127.0.0.1-vs-localhost env artifact, unrelated).

This is the 4th tsc-only break to land on main because the pipeline runs vitest + eslint but not tsc -b. Worth adding a tsc -b (or npm run build) step that runs without a warm incremental cache, since incremental masks exactly this class.

A clean `npm run build` (fresh `.tsbuildinfo`, i.e. what CI / a fresh checkout gets) fails on main at 8408689 with 3 type-only errors. The #359 merge (cd17813, !867) added `terraTxHash.ts` and `terraWalletSignTxRaw.ts`, which carry them; an **incremental** build with a warm cache masks all three, which is why it slipped past the merge and my own earlier build check. `typescript@5.9.3` and `@types/node@22.19.15` are both lockfile-pinned, so this is exactly what CI hits — not a local float. The errors (all type-only, runtime is correct): - `terraTxHash.ts:6` — `txRaw.toBinary()` returns `Uint8Array<ArrayBufferLike>`; `crypto.subtle.digest` wants `BufferSource` under the TS 5.9 lib. Asserted `as BufferSource`. - `terraWalletSignTxRaw.ts:109` — the dev `MnemonicWallet` sets `id` `'mnemonic'`, which is outside the cosmes `WalletName` enum, so `w.id === 'mnemonic'` was a no-overlap comparison. Compared `as string` (preserves the check). - `terraWalletSignTxRaw.ts:116` — `ConnectedWallet.sequence` is private, blocking `wallet as { sequence?: bigint }`. Routed through `as unknown as`. No behavior change. Clean `npm run build` green after; full vitest 594/596 (the 2 fails are the known terraExplorer `127.0.0.1`-vs-`localhost` env artifact, unrelated). This is the 4th tsc-only break to land on main because the pipeline runs vitest + eslint but not `tsc -b`. Worth adding a `tsc -b` (or `npm run build`) step that runs **without** a warm incremental cache, since incremental masks exactly this class.

Brouie commented

2026-06-12 04:52:52 +00:00

(Migrated from gitlab.com)

mentioned in issue #337

PlasticDigits commented

2026-06-12 04:53:39 +00:00

(Migrated from gitlab.com)

Security review

Commit reviewed: 317ad1c670c4c187ff3b09f11bdd207ccfb10e1a
Scope: 2 files — frontend-dapp/src/utils/terraTxHash.ts, frontend-dapp/src/services/terraclassic/terraWalletSignTxRaw.ts (TypeScript compile fixes for #359 signing/hash code; no runtime logic changes).

Outcome: FINDINGS: 0 medium+

Summary: Reviewed the full MR diff and traced each change through callers (signTerraTxRaw → terraBroadcast.ts split-sign/recovery path). All three edits are erased-at-compile-time type assertions:

bytes as BufferSource — txRaw.toBinary() already yields a Uint8Array valid for crypto.subtle.digest; cast satisfies TS 5.9 lib only.
(w.id as string) === 'mnemonic' — preserves the existing dev-wallet branch detection; wallet objects originate from cosmes connection, not attacker-controlled strings.
wallet as unknown as { sequence?: bigint } — same sequence-bump behavior as pre-MR direct cast; signedSequence is sourced from getAuthInfo / signing, not user input.

No new injection surfaces, authn/authz changes, secret exposure, unsafe deserialization, or signing/fee-guard bypass. Prior security-review threads: none on this MR.

Inline threads: none (no findings).

## Security review **Commit reviewed:** `317ad1c670c4c187ff3b09f11bdd207ccfb10e1a` **Scope:** 2 files — `frontend-dapp/src/utils/terraTxHash.ts`, `frontend-dapp/src/services/terraclassic/terraWalletSignTxRaw.ts` (TypeScript compile fixes for #359 signing/hash code; no runtime logic changes). **Outcome:** `FINDINGS: 0` medium+ **Summary:** Reviewed the full MR diff and traced each change through callers (`signTerraTxRaw` → `terraBroadcast.ts` split-sign/recovery path). All three edits are erased-at-compile-time type assertions: 1. `bytes as BufferSource` — `txRaw.toBinary()` already yields a `Uint8Array` valid for `crypto.subtle.digest`; cast satisfies TS 5.9 lib only. 2. `(w.id as string) === 'mnemonic'` — preserves the existing dev-wallet branch detection; wallet objects originate from cosmes connection, not attacker-controlled strings. 3. `wallet as unknown as { sequence?: bigint }` — same sequence-bump behavior as pre-MR direct cast; `signedSequence` is sourced from `getAuthInfo` / signing, not user input. No new injection surfaces, authn/authz changes, secret exposure, unsafe deserialization, or signing/fee-guard bypass. Prior security-review threads: none on this MR. **Inline threads:** none (no findings).

Brouie commented

2026-06-12 06:27:18 +00:00

(Migrated from gitlab.com)

mentioned in issue #368