Indexer fetches only one of the two sequential events

[chlenc]

Indexer fetches only one of the two sequential events

Hi guys, hope you are doing well ☀️ Rn we are still working on the spark spot market and we have faced a next problem: In our match function we have 2 sequential logs

We noticed that the indexer handled it successfully only first of them

I created a simple code to show the problem more clear:

In that example we are have 2 projects:

contract and testnet test

Network: http://beta-4.fuel.network/graphql
Contract ID: fuel1pztzy59xunq2scsq9tkufxnqm35kpqnwxzwu70ejtq936yt5f06qvkettc
Contract ID: 0x08962250a6e4c0a862002aedc49a60dc6960826e309dcf3f32580b1d11744bf4
Deployed in block 0x5e2a917d2c7ee5d4ba082af58214d6b515177df916fec405be335ef19fdc90ba

• contract code https://github.com/chlenc/indexer-issue/blob/master/contract/src/main.sw

• test code https://github.com/chlenc/indexer-issue/blob/master/contract/tests/testnet_tests/mod.rs

indexer

• lib.rs https://github.com/chlenc/indexer-issue/blob/master/test-contract-indexer/src/lib.rs

How to reproduce

0) clone the repo

git clone https://github.com/chlenc/indexer-issue.git
cd indexer-issue

1) Run database and fuel-indexer service and deploy the indexer

# Run database and `fuel-indexer` 

## deploy the indexer
 cd indexer-issue
 cd test-contract-indexer
 forc index deploy

2) Trigger the contract call

cd contract
echo "ADMIN=<YOUR_PK>" >> .env  
cargo test

And you will see only that output

But I'm expected to see n=2 as well

Toolchain

Default host: aarch64-apple-darwin
fuelup home: /Users/alexey/.fuelup

installed toolchains
--------------------
beta-3-aarch64-apple-darwin
beta-4-rc.2-aarch64-apple-darwin
latest-aarch64-apple-darwin (default)
beta-4-aarch64-apple-darwin
hotfix
my-custom-toolchain

active toolchain
-----------------
latest-aarch64-apple-darwin (default)
  forc : 0.46.0
    - forc-client
      - forc-deploy : 0.46.0
      - forc-run : 0.46.0
    - forc-doc : 0.46.0
    - forc-explore : 0.28.1
    - forc-fmt : 0.46.0
    - forc-index : 0.21.0
    - forc-lsp : 0.46.0
    - forc-tx : 0.46.0
    - forc-wallet : 0.3.0
  fuel-core : 0.20.5
  fuel-core-keygen : Error getting version string
  fuel-indexer : 0.21.0

fuels versions
---------------
forc : 0.45
forc-wallet : 0.45

[ra0x3]

@chlenc

• We can help you with some more debugging steps:
  1. Try removing contract_id in your manifest and making it empty. contract_id: ~
  2. Rebuild, then redeploy your indexer
  3. Now call your contract again.
     • Does your test event now trigger?
     • If not, can you confirm that the actual contract method is being called? (by just printing out the results of the contract call)
       • We first want to confirm that test_function() is being called

[chlenc]

@ra0x3

1. my manifest:

   ---
   namespace: composabilitylabs
   identifier: test_contract_indexer
   abi: "./contract-abi.json"
   fuel_client: ~
   graphql_schema: schema/test_contract_indexer.schema.graphql
   module:
   wasm: target/wasm32-unknown-unknown/release/test_contract_indexer.wasm
   metrics: ~
   contract_id: ~
   start_block: 4563050
   end_block: ~
   resumable: true

2. rebuild and redeploy

   >>> forc index build && forc index deploy  
   ▹▹▹▸▹ ⏰ Building indexer...                                                                                                                              Finished release [optimized] target(s) in 0.17s
   ▪▪▪▪▪ ✅ Build succeeded.                                                                                                                             
   ▸▹▹▹▹ ⏰ Building indexer...                                                                                                                              Finished release [optimized] target(s) in 0.14s
   ▪▪▪▪▪ ✅ Build succeeded.                                                                                                                             Deploying indexer...
   ▪▪▪▪▪ ✅ Successfully deployed indexer. 

3. After contract call I still can see test event in the logs, but there is no contract address in manifest

   

4. contract call confirm

   

[ra0x3]

@chlenc Gonna look into this more today

[ra0x3]

@chlenc I'll need you to show me the receipts that are returned from your contract call.

For example, this function in our test smart contract:

    fn trigger_multiargs() -> Ping {
        log(Pung {
            id: 123,
            value: 54321,
            is_pung: false,
            pung_from: Identity::ContractId(ContractId::from(0x322ee5fb2cabec472409eb5f9b42b59644edb7bf9943eda9c2e3947305ed5e96)),
        });

        log(Pong { id: 45678, value: 45678 });

        Ping { id: 12345, value: 12345, message: "a multiarg ping entity          " }
    }

When called like this:

        let r = state
            .contract
            .methods()
            .trigger_multiargs()
            .tx_params(tx_params())
            .call()
            .await
            .unwrap();
        println!("{r:?}"); // <-- this is where we print the receipts

Generates the following output:

FuelCallResponse { 
  value: 
  Ping { 
    id: 12345, 
    value: 12345, 
    message: SizedAsciiString { 
      data: "a multiarg ping entity          " 
    }
  }, 
  receipts: [
    Call { 
      id: 0000000000000000000000000000000000000000000000000000000000000000, 
      to: b97c8abbce1b99e3f5b43038684738fc5e682f8040a0eaf181ed91e212e769f5, 
      amount: 0, 
      asset_id: 0000000000000000000000000000000000000000000000000000000000000000, 
      gas: 999810, 
      param1: 2077681679, 
      param2: 1, 
      pc: 11632, 
      is: 11632 
    }, 
    LogData { 
      id: b97c8abbce1b99e3f5b43038684738fc5e682f8040a0eaf181ed91e212e769f5, 
      ra: 0, 
      rb: 7, 
      ptr: 20392, 
      len: 64, 
      digest: 22efee1d7508c95946747aad0f920c42e04dabb20e8ce029d2ad8accfb202d5b, 
      pc: 13892, 
      is: 11632, 
      data: Some(000000000000007b0000000000...) 
    }, 
    LogData { 
      id: b97c8abbce1b99e3f5b43038684738fc5e682f8040a0eaf181ed91e212e769f5, 
      ra: 0, 
      rb: 8, 
      ptr: 20456, 
      len: 16, 
      digest: 6f704a6ba83cdaf24ee1d6d8c79b999d2c4540e895d1289839a81b12125a1c20, 
      pc: 13932, 
      is: 11632, 
      data: Some(000000000000b26e000000000000b26e) 
    }, 
    ReturnData { 
      id: b97c8abbce1b99e3f5b43038684738fc5e682f8040a0eaf181ed91e212e769f5, 
      ptr: 20472, 
      len: 48, 
      digest: 6f9302e982f0bd5d4984d752c37081629b4514600806fb7cd87775e44e093dc6, 
      pc: 13976, 
      is: 11632, 
      data: Some(00000000000030390000000000...) 
    }, 
    Return { 
      id: 0000000000000000000000000000000000000000000000000000000000000000, 
      val: 1, 
      pc: 10372, 
      is: 10344 
    }, 
    ScriptResult { 
      result: Success, 
      gas_used: 372 
    }
  ], 
  gas_used: 372, 
  log_decoder: LogDecoder { 
    log_formatters: {
      LogId(b97c8abbce1b99e3f5b43038684738fc5e682f8040a0eaf181ed91e212e769f5, 0): LogFormatter { 
        type_id: TypeId { t: 163801745340360138096866111397325763318 }
      }, 
      LogId(b97c8abbce1b99e3f5b43038684738fc5e682f8040a0eaf181ed91e212e769f5, 3): LogFormatter { 
        type_id: TypeId { t: 168527957863626225602967657224886506611 }
      }, 
      LogId(b97c8abbce1b99e3f5b43038684738fc5e682f8040a0eaf181ed91e212e769f5, 8): LogFormatter { 
        type_id: TypeId { t: 89429155306611214123602189586076641335 }
      },
      LogId(b97c8abbce1b99e3f5b43038684738fc5e682f8040a0eaf181ed91e212e769f5, 1): LogFormatter {
        type_id: TypeId { t: 329357769005237210867352791584655462874 } 
      }, 
      LogId(b97c8abbce1b99e3f5b43038684738fc5e682f8040a0eaf181ed91e212e769f5, 2): LogFormatter { 
        type_id: TypeId { t: 261420450695421989069451487868004229693 } 
      }, 
      LogId(b97c8abbce1b99e3f5b43038684738fc5e682f8040a0eaf181ed91e212e769f5, 6): LogFormatter { 
        type_id: TypeId { t: 160074500918331608558713563116476414676 } 
      }, 
      LogId(b97c8abbce1b99e3f5b43038684738fc5e682f8040a0eaf181ed91e212e769f5, 7): LogFormatter { 
        type_id: TypeId { t: 160074500918331608558713563116476414676 } 
      },
      LogId(b97c8abbce1b99e3f5b43038684738fc5e682f8040a0eaf181ed91e212e769f5, 9): LogFormatter { 
        type_id: TypeId { t: 211145317803461539246944466681743340709 } 
      }, 
      LogId(b97c8abbce1b99e3f5b43038684738fc5e682f8040a0eaf181ed91e212e769f5, 5): LogFormatter { 
        type_id: TypeId { t: 211145317803461539246944466681743340709 } 
      }, 
      LogId(b97c8abbce1b99e3f5b43038684738fc5e682f8040a0eaf181ed91e212e769f5, 10): LogFormatter { 
        type_id: TypeId { t: 305780301139136408623987491295302957952 } 
      }, 
      LogId(b97c8abbce1b99e3f5b43038684738fc5e682f8040a0eaf181ed91e212e769f5, 11): LogFormatter { 
        type_id: TypeId { t: 6703069141550089932305262084755375902 } 
      }, 
      LogId(b97c8abbce1b99e3f5b43038684738fc5e682f8040a0eaf181ed91e212e769f5, 4): LogFormatter { 
        type_id: TypeId { t: 180243464385374823718625000331620167948 } 
      }, 
      LogId(b97c8abbce1b99e3f5b43038684738fc5e682f8040a0eaf181ed91e212e769f5, 12): LogFormatter { 
        type_id: TypeId { t: 5893892842673059497638093081769943588 } }
      }
    }, 
  tx_id: Some(626f3d23d8b7e20132e80e83db1fba831ec443d01c60919e2f54d300d338ce2e) 
}

@chlenc

• As you can see in the output ☝🏼 , we have 2 LogData receipts, so 2 events are decoded by the indexer
• In order to help you, I need to see the output of your contract call
  • If the contract call result has 2 LogData receipts, then there is a bug somewhere
  • But if the contract call result only has 1 LogData receipt, then one of your log(TestEvent) is clobbering the other one :)

[ra0x3]

@chlenc

• Ok I think I have a resolution, thanks for the patience
• You are trying to receive two TestEvent events from one contract call to the same contract method
• However, the Fuel indexer only allows for one single item to be dispatched from the decoder at a time
  • That code is here
  • This is very much by design, because the indexer does not support Vec types (and two TestEvents would have to be contained inside of some struct (e.g., Vec))
• As a workaround - you'd have to make two distinct calls to your contract method :)