relayer-cli/src/utils/graphQueries.ts (3)

4-20: Prefer GraphQL variables over string interpolation and reduce log noise

• Build queries with variables to avoid injection/escaping issues and to improve caching.
• Consider gating console.log behind a DEBUG/LOG_LEVEL env.

Example:

-const query = `{messageSents(first: 1, where: {nonce: ${nonce}, inbox: "${inboxAddress}"}) { id transactionHash }}`
-const result = await request(url, query)
+const query = `query($nonce: Int!, $inbox: String!) {
+  messageSents(first: 1, where: { nonce: $nonce, inbox: $inbox }) { id transactionHash }
+}`
+const result = await request(url, query, { nonce, inbox: inboxAddress })

---

2-2: Type safety note

Defining a minimal common interface for veaOutbox (e.g., with stateRoot()) allows easier mocking and testing across chains. Based on learnings.

---

12-19: Error handling is fine; consider structured logging

Catching and returning [] is acceptable here; add context (nonce/inbox) to the log object for observability.

relayer-cli/.env.dist (1)

24-27: Lint warnings vs. intended quoting; add trailing newline

• Quotes around STATE_DIR are intentional; keep as-is. Based on learnings.
• Add a newline at EOF to appease linters.

 HASHI_EXECUTOR_ENABLED=true
+ 

Optional: default to false in dist to prevent accidental enablement in new setups.

relayer-cli/src/utils/relay.test.ts (1)

64-65: Test fixture updated to [to, from, data]

Good alignment with the new tuple signature. Consider asserting that the encoded calldata reflects inclusion of the “from” parameter to prevent regressions.

relayer-cli/src/utils/logger.ts (1)

63-72: Add a handler for HASHI_EXECUTION_FAILED to surface errors

You emit a failure event in BotEvents but don’t log it here. Add an error listener for parity with MESSAGE_EXECUTION_FAILED.

Suggested diff:

   // Hashi executor logs
   emitter.on(BotEvents.EXECUTING_HASHI, (startNonce, endNonce) => {
     console.log(`Executing Hashi for nonces from ${startNonce} to ${endNonce}`);
   });
   emitter.on(BotEvents.HASHI_EXECUTED, (endNonce) => {
     console.log(`Successfully executed Hashi till ${endNonce}`);
   });
   emitter.on(BotEvents.HASHI_BATCH_TXN, (txHash, batchSize) => {
     console.log(`Hashi batch transaction ${txHash} for ${batchSize} messages`);
   });
+  emitter.on(BotEvents.HASHI_EXECUTION_FAILED, (failedNonce, reason) => {
+    console.error(`Hashi execution failed at nonce ${failedNonce}`, reason);
+  });

relayer-cli/src/utils/botEvents.ts (1)

21-25: Enum additions LGTM; ensure consumers handle failure event

New Hashi events look good. Confirm logger binds HASHI_EXECUTION_FAILED (and it emits error-level logs).

relayer-cli/src/consts/bridgeRoutes.ts (1)

20-24: Parameterize Hashi/Yaru/Yaho addresses and verify correctness per chain

Hard-coding addresses risks drift across envs. Prefer env vars (e.g., HASHI_YAHO_ARBITRUM_SEPOLIA, HASHI_YARU_SEPOLIA, HASHI_HASHI_SEPOLIA, etc.) and document required values. Also confirm these addresses are correct for 11155111 and 10200 and that rpcInbox pointing to RPC_ARBITRUM_SEPOLIA is intentional for both.

Also applies to: 67-71, 79-83

relayer-cli/src/utils/hashi.test.ts (1)

6-14: Reuse shared MockEmitter to avoid duplication

There’s already a MockEmitter utility (validator-cli/src/utils/emitter.ts). Reuse it here to reduce duplication and keep behavior consistent.

relayer-cli/src/utils/hashiHelpers/hashiMsgUtils.ts (1)

11-23: Prefer public ethers APIs and correct return typing

• Use bigint (primitive) as return type for getHashiMsgId.
• Replace internal toBeArray with getBytes and validate 32‑byte length.
• Since you now accept Uint8Array in HashiMessage.data (see types suggestion), the data branch remains correct.

Suggested diff:

 export function getHashiMsgId(
   sourceChainId: bigint | number | string,
   dispatcherAddress: string,
   message: HashiMessage
-): BigInt {
+): bigint {
   // Normalize exactly as Solidity would see inputs
   const source = BigInt(sourceChainId);
   const dispatcher = getAddress(dispatcherAddress); // checksum normalize

   const msgHash = calculateMessageHash(message);
   const encodedId = coder.encode(["uint256", "address", "bytes32"], [source, dispatcher, msgHash]);
   return hexToBigInt32Bytes(keccak256(encodedId));
 }
@@
-function hexToBigInt32Bytes(hex32: string): bigint {
-  const bytes = toBeArray(hex32);
+function hexToBigInt32Bytes(hex32: string): bigint {
+  const bytes = getBytes(hex32);
+  if (bytes.length !== 32) {
+    throw new Error(`Expected 32-byte hex string, got ${bytes.length} bytes`);
+  }
   // Convert bytes to BigInt (big-endian)
   let n = BigInt(0);
   for (const b of Array.from(bytes)) {
     n = (n << BigInt(8)) + BigInt(b);
   }
   return n;
 }

Also applies to: 34-41, 56-64

relayer-cli/src/utils/relay.ts (1)

127-133: Doc nit: update JSDoc param name.

Comment says @param msgSender but code uses msgSenders: string[].

- * @param msgSender The address of the sender
+ * @param msgSenders The addresses of the senders

relayer-cli/src/utils/hashi.ts (2)

24-45: Typo in function name: toExecuteMesssage.

Three “s” makes grepping/imports error-prone; consider renaming to toExecuteMessage and re-exporting an alias for backward compatibility.

---

229-235: Remove stray console.log; use BotEvents if needed.

console.log("Message already executed flag:", flag); is noisy in prod paths.

-    console.log("Message already executed flag:", flag);

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: mani99brar
PR: kleros/vea#430
File: contracts/src/interfaces/inboxes/IVeaInbox.sol:0-0
Timestamp: 2025-08-27T07:02:45.825Z
Learning: The sendMessage signature simplification in IVeaInbox.sol and related call site updates across relay-cli and test files were fixed in a separate PR by mani99brar.

Learnt from: mani99brar
PR: kleros/vea#370
File: bridger-cli/src/consts/bridgeRoutes.ts:28-30
Timestamp: 2024-12-10T08:00:35.645Z
Learning: In `bridger-cli/src/consts/bridgeRoutes.ts`, additional validation in the `getBridgeConfig` function is unnecessary because error handling and validation are managed by upper layers in the application.

Learnt from: mani99brar
PR: kleros/vea#427
File: relayer-cli/.env.dist:24-24
Timestamp: 2025-07-07T12:29:34.770Z
Learning: In relayer-cli/.env.dist, the user (mani99brar) intentionally keeps quotes around environment variable values like `STATE_DIR="/home/user/vea/relayer-cli/state/"` as this works as intended for their use case.

Learnt from: mani99brar
PR: kleros/vea#370
File: bridger-cli/src/utils/graphQueries.ts:36-58
Timestamp: 2024-12-09T09:04:04.819Z
Learning: In `bridger-cli/src/utils/graphQueries.ts` (TypeScript), the `getVerificationStatus` function is no longer needed and has been removed.

Learnt from: mani99brar
PR: kleros/vea#370
File: bridger-cli/src/utils/transactionHandler.ts:13-13
Timestamp: 2024-12-09T09:40:28.400Z
Learning: In `bridger-cli/src/utils/transactionHandler.ts`, the `veaOutbox` implementations differ for each chain, but a common interface should be defined for type checks to enhance type safety.

relayer-cli/src/utils/graphQueries.ts (1)

64-86: Paginate >1000 results and use variables; normalize casing.

Current query caps at 1000 and may miss older nonces. Use a paginated loop with first/skip and GraphQL variables; keep addresses lowercased. This was flagged earlier; re-iterating with a concrete patch.

-const getNonceFrom = async (chainId: number, inbox: string, nonce: number, msgSender: string) => {
-  const subgraph = process.env.RELAYER_SUBGRAPH;
-
-  const result = (await request(
-    `https://api.studio.thegraph.com/query/${subgraph}`,
-    `{
-        messageSents(
-          first: 1000, 
-          where: {
-            inbox: "${inbox}",
-            nonce_gte: ${nonce}, 
-            msgSender_: {id: "${msgSender.toLowerCase()}"}
-          }, 
-          orderBy: nonce, 
-          orderDirection: asc
-        ) {
-          nonce
-        }
-      }`
-  )) as MessageSentsResponse;
-
-  return result[`messageSents`].map((a: { nonce: string | number }) => Number(a.nonce));
-};
+const getNonceFrom = async (_chainId: number, inbox: string, nonce: number, msgSender: string) => {
+  const subgraph = process.env.RELAYER_SUBGRAPH;
+  if (!subgraph) throw new Error("Missing RELAYER_SUBGRAPH");
+  const endpoint = `https://api.studio.thegraph.com/query/${subgraph}`;
+  const query = gql`
+    query MsgsFrom($inbox: String!, $nonce: BigInt!, $sender: String!, $first: Int!, $skip: Int!) {
+      messageSents(
+        first: $first
+        skip: $skip
+        where: { inbox: $inbox, nonce_gte: $nonce, msgSender_: { id: $sender } }
+        orderBy: nonce
+        orderDirection: asc
+      ) {
+        nonce
+      }
+    }
+  `;
+  const first = 1000;
+  let skip = 0;
+  const acc: number[] = [];
+  for (;;) {
+    const vars = { inbox: inbox.toLowerCase(), nonce, sender: msgSender.toLowerCase(), first, skip };
+    const page = (await request(endpoint, query, vars)) as MessageSentsResponse;
+    const items = page.messageSents;
+    acc.push(...items.map((a) => Number(a.nonce)));
+    if (items.length < first) break;
+    skip += first;
+  }
+  return acc;
+};

relayer-cli/src/utils/graphQueries.ts (1)

31-47: Remove or underscore unused parameter; add ENV guard and variables in getCount.

chainId is unused; mark as _chainId to satisfy TS and future use. Also guard RELAYER_SUBGRAPH and use variables.

-const getCount = async (veaOutbox: VeaOutboxArbToEth | VeaOutboxArbToGnosis, chainId: number): Promise<number> => {
-  const subgraph = process.env.RELAYER_SUBGRAPH;
+const getCount = async (veaOutbox: VeaOutboxArbToEth | VeaOutboxArbToGnosis, _chainId: number): Promise<number> => {
+  const subgraph = process.env.RELAYER_SUBGRAPH;
+  if (!subgraph) throw new Error("Missing RELAYER_SUBGRAPH");
   const stateRoot = await veaOutbox.stateRoot();
 
-  const result = (await request(
-    `https://api.studio.thegraph.com/query/${subgraph}`,
-    `{
-      snapshotSaveds(first: 1, where: { stateRoot: "${stateRoot}" }) {
-        count
-      }
-    }`
-  )) as SnapshotResponse;
+  const endpoint = `https://api.studio.thegraph.com/query/${subgraph}`;
+  const query = gql`
+    query SnapByRoot($stateRoot: Bytes!) {
+      snapshotSaveds(first: 1, where: { stateRoot: $stateRoot }) {
+        count
+      }
+    }
+  `;
+  const result = (await request(endpoint, query, { stateRoot })) as SnapshotResponse;
 
-  if (result["snapshotSaveds"].length == 0) return 0;
+  if (result.snapshotSaveds.length === 0) return 0;
 
-  return Number(result["snapshotSaveds"][0].count);
+  return Number(result.snapshotSaveds[0].count);
 };

relayer-cli/src/utils/hashi.ts (6)

11-11: Hardcoded SOURCE_CHAIN_ID OK for current scope; add TODO.

Accepted per project context (Arbitrum Sepolia only). Add a reminder for future multi-route support.

-const SOURCE_CHAIN_ID = 421614; // Arbitrum Sepolia
+const SOURCE_CHAIN_ID = 421614; // Arbitrum Sepolia
+// TODO: Make source chain id configurable when enabling non-Arbitrum routes.

Based on learnings.

---

36-61: Reuse provider and log interface across the loop to cut overhead.

Currently a new provider/interface can be constructed per nonce (via defaults). Build once and pass in.

 async function runHashiExecutor({
@@
   const bridgeConfig = fetchBridgeConfig(chainId);
   const { veaContracts, rpcInbox } = bridgeConfig;
   const veaInboxAddress = veaContracts[network].veaInbox.address;
   const privateKey = process.env.PRIVATE_KEY;
   const veaInbox = fetchVeaInbox(veaInboxAddress, privateKey, rpcInbox, chainId);
+  const providerInbox = new JsonRpcProvider(rpcInbox);
+  const logIFace = new Interface(messageDispatchedAbi);
   const inboxCount = await veaInbox.count();
@@
-    const toExecute = await isMessageExecutable({ chainId, nonce, veaInboxAddress, rpcInbox });
+    const toExecute = await isMessageExecutable({
+      chainId,
+      nonce,
+      veaInboxAddress,
+      rpcInbox,
+      provider: providerInbox,
+      logIFace,
+    });

---

80-86: Optional: inject signer/private key for testability and clearer failures.

Keep env handling upstream if desired, but allowing an injected signer (or privateKey param) decouples this util from process.env.

-  const provider = new JsonRpcProvider(rpcOutbox);
-  const signer = new Wallet(process.env.PRIVATE_KEY!, provider);
+  const provider = new JsonRpcProvider(rpcOutbox);
+  // Consider: accept a signer/privateKey param; fallback to env for convenience.
+  const signer = new Wallet(process.env.PRIVATE_KEY!, provider);

Based on learnings.

---

162-176: Consider early-config checks for Yaho address; clearer error if misconfigured.

Fail-fast on missing yahoAddress before decoding to improve diagnostics; optional per your fail-fast stance on hashes.

   const hashes = await fetchVeaMsgTrnx(nonce, veaInboxAddress);
   const bridgeConfig = fetchBridgeConfig(chainId);
-  const yahoAddress = bridgeConfig.yahoAddress?.toLowerCase();
+  const yahoAddress = bridgeConfig.yahoAddress?.toLowerCase();
+  if (!yahoAddress) throw new Error("Missing yahoAddress in bridge config");

---

211-240: Message ID domain/dispatcher selection — defer change, track via TODO.

Using SOURCE_CHAIN_ID and bridgeConfig(message.targetChainId) is acceptable for current Arbitrum-only routes. Add a TODO to derive domain + dispatcher from the source chain config when expanding routes.

-  const domain = BigInt(SOURCE_CHAIN_ID); // uint256
-  const id = getHashiMsgId(SOURCE_CHAIN_ID, bridgeConfig.yahoAddress!, message); // bytes32
+  const domain = BigInt(SOURCE_CHAIN_ID); // uint256
+  const id = getHashiMsgId(SOURCE_CHAIN_ID, bridgeConfig.yahoAddress!, message); // bytes32
+  // TODO: When adding more routes, compute ID with the source chain's dispatcher and chain id.

Based on learnings.

---

242-242: Typo in exported function name; add alias to ease future rename.

Function is spelled toExecuteMesssage. Consider exporting an alias now to avoid breakage later.

-export { executeBatchOnHashi, runHashiExecutor, toExecuteMesssage };
+export { executeBatchOnHashi, runHashiExecutor, toExecuteMesssage };
+// Back-compat alias; safe to remove after repo-wide rename.
+export { toExecuteMesssage as toExecuteMessage };

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: mani99brar
PR: kleros/vea#434
File: relayer-cli/src/utils/hashi.ts:206-235
Timestamp: 2025-10-27T13:45:23.401Z
Learning: The Hashi executor in relayer-cli currently only supports routes from Arbitrum Sepolia (chain ID 421614), so the hardcoded SOURCE_CHAIN_ID constant in relayer-cli/src/utils/hashi.ts is acceptable for the current scope. This will be updated when support for other source chains is added.

Learnt from: mani99brar
PR: kleros/vea#370
File: bridger-cli/src/utils/ethers.ts:20-82
Timestamp: 2024-12-09T10:18:00.133Z
Learning: In `bridger-cli/src/utils/ethers.ts`, prefer to keep the existing `chainId` checks without refactoring to avoid overcomplicating the code with additional conditional logic.

Learnt from: fcanela
PR: kleros/vea#344
File: validator-cli/src/utils/arbMsgExecutor.ts:14-14
Timestamp: 2024-11-19T10:25:55.588Z
Learning: In the `validator-cli/src/utils/arbMsgExecutor.ts` file, checks for commonly required environment variables like `PRIVATE_KEY` should be performed earlier in the application lifecycle, before individual functions are executed.

Learnt from: madhurMongia
PR: kleros/vea#359
File: validator-cli/src/utils/arbMsgExecutor.ts:13-13
Timestamp: 2024-11-20T11:50:12.303Z
Learning: In the `validator-cli` codebase, when initializing `Wallet` instances in TypeScript, it's acceptable to rely on the `Wallet` class's built-in validation of the private key retrieved from environment variables, without adding explicit checks for the existence of `PRIVATE_KEY`.

Learnt from: mani99brar
PR: kleros/vea#434
File: relayer-cli/src/utils/hashi.ts:80-86
Timestamp: 2025-10-27T13:46:03.446Z
Learning: In the relayer-cli codebase, when initializing Wallet instances, it's acceptable to rely on the Wallet class's built-in validation of the private key retrieved from environment variables, without adding explicit checks for the existence of PRIVATE_KEY.

Learnt from: mani99brar
PR: kleros/vea#370
File: bridger-cli/src/utils/transactionHandler.ts:13-13
Timestamp: 2024-12-09T09:40:28.400Z
Learning: In `bridger-cli/src/utils/transactionHandler.ts`, the `veaOutbox` implementations differ for each chain, but a common interface should be defined for type checks to enhance type safety.

Learnt from: mani99brar
PR: kleros/vea#370
File: bridger-cli/src/utils/graphQueries.ts:36-58
Timestamp: 2024-12-09T09:04:04.819Z
Learning: In `bridger-cli/src/utils/graphQueries.ts` (TypeScript), the `getVerificationStatus` function is no longer needed and has been removed.

relayer-cli/src/utils/hashi.test.ts (2)

1-231: Verify function name typo in hashi.ts.

The past review flagged a typo toExecuteMesssage (triple 's') in hashi.ts at lines 20, 43, 157, and 237. While this test file's imports use the correct spelling, ensure the actual function definition and all its references in hashi.ts have been corrected to toExecuteMessage.

Run the following script to check for any remaining instances of the typo:

#!/bin/bash
# Description: Search for the typo 'toExecuteMesssage' (triple 's') in hashi.ts and related files

# Search for the typo with triple 's'
echo "Checking for typo 'toExecuteMesssage' (triple 's'):"
rg -n 'toExecuteMesssage' relayer-cli/src/utils/

# Verify correct spelling exists
echo -e "\nVerifying correct spelling 'toExecuteMessage':"
rg -n 'toExecuteMessage' relayer-cli/src/utils/hashi.ts -C 1 | head -20

---

101-117: Type mismatch: HashiMessage numeric fields should be bigint.

Line 116 expects hashiMessage.nonce to be BigInt(1), but the HashiMessage interface defines nonce (along with targetChainId and threshold) as number. This creates a type mismatch since:

• Decoded event logs return BigInt values (lines 85-87)
• Test assertions expect BigInt (line 116)
• But the type definition specifies number

Update hashiTypes.ts to define these three fields as bigint to align with runtime behavior and eliminate type inconsistencies.

relayer-cli/src/utils/hashi.test.ts (1)

6-14: Extract MockEmitter to shared test utilities.

This class duplicates the identical MockEmitter from validator-cli/src/utils/emitter.ts. To avoid code duplication and maintain consistency across test files, extract it to a shared test utilities module (e.g., test-utils/mockEmitter.ts) that both validator-cli and relayer-cli can import.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro