[BUG] Block/Header RPCs Fail with a `verbosity` Argument

[phroi]

Hello folks at CKB DevRel,

I noticed that the block/header methods fail whenever verbosity is passed.

Minimal Reproduction

import { ccc } from "@ckb-ccc/core";

const owner = ccc.ClientPublicTestnet.open();
const client = owner.value;
for (const read of [
  () => client.getTipHeader(0),
  () => client.getTipHeader("0x0" as never),
  () => client.getBlockByNumber(1, "0x0" as never),
  () => client.getBlockByNumber(1, "0x2" as never, true),
]) {
  console.log(await read().catch((error) => error.message));
}
await owner.dispose();

Behavior

Invalid parameter for `verbosity`: invalid type: integer `0`, expected a hex-encoded, 0x-prefixed Uint32
undefined is not iterable (cannot read property Symbol(Symbol.iterator))
Cannot read properties of undefined (reading 'dao')
Cannot read properties of undefined (reading 'dao')

The senders encode only the block number or hash, so a numeric verbosity reaches the node as a JSON number instead of the Uint32 hex string the node expects. A hex string gets past the node, but the serialized bytes and the with_cycles response then reach transformers that expect a decoded header or block. getBlockByHash, getHeaderByNumber and getHeaderByHash fail the same way.

Environment

• @ckb-ccc/core@1.20.0, 1.20.1 and 1.22.0
• Node.js 24.18.0, Linux

Keep up the Great Work,
Phroi %31

[Hanssen0]

Hi Phroi! Before everything, I would like to first appreciate you sharing your findings #557, #558, and #566. They've been fixed and will be released shortly.

For this verbosity issue, I consider introducing it to have been an oversight on my part two years ago. It should be more like an internal optimisation than an API argument, given that it only alters the data format without changing the data content (even though, in some cases, data may be omitted).

I think the appropriate approach is to mark verbosity as deprecated and remove it in the next major release.

Regarding support for with_cycles, my current thought is that perhaps we should introduce a separate API for it, rather than having a single method return two different formats. If you’re willing to share your use case, we might be able to better determine the best approach.

Thanks for the feedback!

[phroi]

Well, thank you for the quick fixes!!

I think the appropriate approach is to mark verbosity as deprecated and remove it in the next major release.

Sounds good to me!!

Regarding support for with_cycles, my current thought is that perhaps we should introduce a separate API for it, rather than having a single method return two different formats.

Your call as BDFL. On my side, client.requestor for cycles works well enough!

Phroi