fix(tests): contract-keyed airdrop sender for HIP904 Batch1

Signed-off-by: ValentinVPK <valentin.krumov@limechain.tech>

Author: ValentinVPK

.github/workflows/tests.yml

@@ -30,8 +30,8 @@ defaults:
     shell: bash
 
 jobs:
-  HRC:
-    name: HRC Test Suite
+  HIP904Batch1:
+    name: HIP904 Contract Test Suite Batch 1
     uses: ./.github/workflows/test-workflow.yml
     with:
-      testfilter: HRC
+      testfilter: HIP904Batch1

test/token-service/hrc-904/AirdropContract.js

@@ -16,6 +16,7 @@ describe('HIP904Batch1 AirdropContract Test Suite', function () {
   let nftTokenAddress;
   let signers;
   let owner;
+  let emptySender;
   let accounts;
   let contractAddresses;
   let walletIHRC904AccountFacade;
@@ -32,14 +33,27 @@ describe('HIP904Batch1 AirdropContract Test Suite', function () {
     erc721Contract = await utils.deployContract(
       Constants.Contract.ERC721Contract,
     );
-    owner = signers[0].address;
     accounts = signers.slice(1, 3).map((s) => s.address);
 
     contractAddresses = [
       await airdropContract.getAddress(),
       await tokenCreateContract.getAddress(),
     ];
-    await hapi.updateAccountKeys(contractAddresses);
+
+    // Relay model: no account re-keying. The Airdrop contract debits the sender
+    // and leaves isApproval false, so the sender's key has to include the
+    // contract — which a hardhat signer cannot have while it still sends
+    // EthereumTransactions. The airdrop sender is therefore a contract-keyed
+    // account that only ever acts as a subject (signers[0] still sends every
+    // transaction), and it is the treasury of every token created below, so it
+    // holds the supply without any seeding transfer.
+    owner = (await hapi.createAccountWithContractIdKey(contractAddresses))
+      .address;
+    // A second contract-keyed account, associated but holding nothing, so the
+    // insufficient-balance test fails on the balance rather than on
+    // authorization or a missing association.
+    emptySender = (await hapi.createAccountWithContractIdKey(contractAddresses))
+      .address;
 
     tokenAddress = await utils.setupToken(
       tokenCreateContract,
@@ -53,6 +67,13 @@ describe('HIP904Batch1 AirdropContract Test Suite', function () {
       contractAddresses,
       hapi,
     );
+    await (
+      await tokenCreateContract.associateTokenPublic(
+        emptySender,
+        tokenAddress,
+        Constants.GAS_LIMIT_1_000_000,
+      )
+    ).wait();
   });
 
   after(function () {
@@ -76,7 +97,7 @@ describe('HIP904Batch1 AirdropContract Test Suite', function () {
 
     const tx = await airdropContract.tokenAirdrop(
       tokenAddress,
-      signers[0].address,
+      owner,
       receiver,
       ftAmount,
       Constants.GAS_LIMIT_2_000_000,
@@ -303,7 +324,7 @@ describe('HIP904Batch1 AirdropContract Test Suite', function () {
 
     const tx = await airdropContract.tokenAirdrop(
       tokenAddress,
-      signers[2].address,
+      emptySender,
       receiver,
       ftAmount,
       Constants.GAS_LIMIT_2_000_000,
@@ -350,7 +371,7 @@ describe('HIP904Batch1 AirdropContract Test Suite', function () {
 
     const tx = await airdropContract.tokenAirdrop(
       tokenAddress,
-      signers[0].address,
+      owner,
       receiver,
       invalidAmount,
       Constants.GAS_LIMIT_2_000_000,
@@ -439,7 +460,7 @@ describe('HIP904Batch1 AirdropContract Test Suite', function () {
 
     const tx = await airdropContract.tokenAirdrop(
       tokenAddress,
-      signers[0].address,
+      owner,
       receiver.address,
       ftAmount,
       {

test/token-service/utils.js

@@ -657,13 +657,17 @@ class Utils {
    * Reads a system contract's response code out of a transaction's mirror node
    * action tree.
    *
-   * The action addressed to the system contract is identified by entity id
-   * (`recipient`) OR by EVM address (`to`) — the entity-id form alone stopped
-   * matching on consensus v0.77 / mirror v0.161. If neither shape is present,
-   * fall back to the innermost action, which is where a facade/redirect call
-   * leaves its response code, and say so in the log: the expected codes the
-   * callers assert on (22 / 178 / 196 / 354 / 367) are precise enough that a
-   * wrong pick fails the assertion rather than passing silently.
+   * Two shapes are both normal, depending on how the precompile was reached:
+   *   - through a contract: the tree has a child action addressed to the system
+   *     contract, matched here by entity id (`recipient`) or EVM address (`to`).
+   *   - directly through a token/account facade (IHRC719, IHRC904, IHRC906): on
+   *     consensus v0.77 there is no child action for the system contract at all.
+   *     The single depth-0 action — whose recipient is the token itself, or null
+   *     for an account facade — carries the response code.
+   * So fall through to the innermost action carrying result_data. For the
+   * contract case that is the same system-contract action the match found, and
+   * the exact codes callers assert on (22 / 178 / 196 / 354 / 367) mean a wrong
+   * pick fails the assertion rather than passing silently.
    *
    * @param {string} txHash - The transaction hash to query.
    * @param {string} entityId - System contract entity id, e.g. '0.0.359'.
@@ -699,9 +703,6 @@ class Utils {
         `No action carrying result_data for ${txHash}; actions=${JSON.stringify(actions)}`,
       );
     }
-    console.log(
-      `[actions] no ${entityId} action for ${txHash}; falling back to depth ${innermost.call_depth} recipient=${innermost.recipient} to=${innermost.to}`,
-    );
     return BigInt(innermost.result_data).toString();
   }