Brigde Indexer refactor

[abheektripathy]

currently, the response from this looks like this

endpoint: /transactions
queryParams: {
    ethAddress?: ""
    availAddress?: ""
    page?: 3
    pageSize?: 25
}
response: {
    result: [
        {
        sourceChain: "AVAIL", // "ETHEREUM"
          destinationChain: "ETHEREUM", // "AVAIL"
          messageId: 24,
          status:"BRIDGED" // "READY_TO_CLAIM" // "CLAIMED"
          sourceTransactionHash: "0xabc", 
          sourceTransactionBlockNumber: 123,
          sourceTransactionIndex: 2,
          sourceTransactionTimestamp: date,
          sourceTokenAddress: "0xabc",
          amount: 1234,
                   dataType: FungibleToken // Message
          depositorAddress: "0xabc",
          receiverAddress: "0xabc",
//below would come once the txn is claimed, they should be ignored when the status is ready_to_claim or IN PROGRESS
          destinationTransactionHash: "0xabc",
          destinationTransactionBlockNumber: 123,
          destinationTransactionTimestamp: date,
          destinationTransactionIndex: 123,
          destinationTokenAddress: "0xabc",
        }, 
        {}
    ],
    paginationData: {
        hasNextPage: true
        page: 0
        pageSize: 25
        totalCount: 100
    }
}

TODOS

• [ ] the query params should have atleast one required, ethAddress or availAddress, also two more params sourceChain="AVAIL" // "ETHEREUM" and destinationChain
• [ ] if the addresses are of the incorrect format, the api should throw an error
• [ ] status currently are "BRIDGED" // "READY_TO_CLAIM" // "CLAIMED" they should be changed to "IN PROGRESS" // "READY_TO_CLAIM" // "CLAIMED"
• [ ] the datatype currently is ERC20 it should be FungibleToken // Message, should have the amount when we have a fungible token or else message

[vibhurajeev]

At the moment there is no ethAddress or availAddress. Also the user address is nullable, to allow querying the entire list of bridge transactions wherever possible. This does not affect the performance in any way, as it is one less filter on the DB query, so I would say it is alright to keep it optional.

[abheektripathy]

@vibhurajeev had a talk with @0xSasaPrsic on this before, userAddress would be changed to ethAddress, availaddress, since i have to query the api twice everytime i need to fetch the transactions on the ui

agree on the optional thing

[0xSasaPrsic]

Instead of passing userAddress as a query param we can pass 2 query params ethAddress and availAddress so that filtering happens on the db level and removes one extra request. If any of those params are not passed then the behavior stays the same. Do we index AMB Message transactions?