update to lastest bridge versions about bridge-ui

[akolotov]

It could relate to your configuration of the contracts and your token bridge. Could you share the corresponding .env files?

[branciard]

here the deployment result :

 Contracts Deployment have been saved to `bridgeDeploymentResults.json`
{
    "homeBridge": {
        "address": "0x37B5914B0F1b17C847F1239383489dBe078F6019",
        "deployedBlockNumber": 217,
        "erc677": {
            "address": "0xd857fA327CfE8128A19AC4d74C133D18c28a4c58"
        }
    },
    "foreignBridge": {
        "address": "0x37B5914B0F1b17C847F1239383489dBe078F6019",
        "deployedBlockNumber": 235
    }
}

Here my token bridge .env file

BRIDGE_MODE=ERC_TO_ERC
HOME_POLLING_INTERVAL=5000
FOREIGN_POLLING_INTERVAL=1000
ALLOW_HTTP=yes
HOME_RPC_URL=http://--valid--ip--here:8545
FOREIGN_RPC_URL=http://-valid--ip--here:9545
HOME_BRIDGE_ADDRESS=0x37B5914B0F1b17C847F1239383489dBe078F6019
FOREIGN_BRIDGE_ADDRESS=0x37B5914B0F1b17C847F1239383489dBe078F6019
ERC20_TOKEN_ADDRESS=0x9Abfcd68c61E6C6C673c981e5DB658283Bf19dbD

VALIDATOR_ADDRESS=0xabcd1339Ec7e762e639f4887E2bFe5EE8023E23E
VALIDATOR_ADDRESS_PRIVATE_KEY=--valid--private--key--here

HOME_GAS_PRICE_ORACLE_URL=https://gasprice.poa.network/
HOME_GAS_PRICE_SPEED_TYPE=standard
HOME_GAS_PRICE_FALLBACK=1000000000
HOME_GAS_PRICE_UPDATE_INTERVAL=600000

FOREIGN_GAS_PRICE_ORACLE_URL=https://gasprice.poa.network/
FOREIGN_GAS_PRICE_SPEED_TYPE=standard
FOREIGN_GAS_PRICE_FALLBACK=1000000000
FOREIGN_GAS_PRICE_UPDATE_INTERVAL=600000


#QUEUE_URL=amqp://127.0.0.1
#QUEUE_URL=amqp://rabbit
QUEUE_URL=amqp://rabbit:5672
#QUEUE_URL=amqp://rabbit:5673?

#REDIS_URL=redis://127.0.0.1:6379
REDIS_URL=redis://redis:6379

REDIS_LOCK_TTL=1000

HOME_START_BLOCK=217
FOREIGN_START_BLOCK=235

LOG_LEVEL=error
MAX_PROCESSING_TIME=20000

#testing accs
USER_ADDRESS=0xabcd1339Ec7e762e639f4887E2bFe5EE8023E23E
USER_ADDRESS_PRIVATE_KEY=--valid--private--key--here
HOME_MIN_AMOUNT_PER_TX=0.001
FOREIGN_MIN_AMOUNT_PER_TX=0.001
HOME_TEST_TX_GAS_PRICE=1000000000
FOREIGN_TEST_TX_GAS_PRICE=1000000000

Reading the env.example history I see that VALIDATOR_ADDRESS has been removed here :
omni/token-bridge@8fcb8ba#diff-cbfd64a28982a1818f2b5f16e7f9d634
but still present in docker-compose : https://github.com/poanetwork/token-bridge/blob/master/docker-compose.yml#L53 . Maybe there is something wrong with the VALIDATOR_ADDRESS usage.

[akolotov]

Right. it could be. I need more time to investigate. We changed a procedure to run containers in order to hide the validator's private key if its address is only needed. So, probably we didn't reflect this in the documentation.

[branciard]

In fact, I observe random behaviour, sometimes it passes, sometimes it stays stuck at "Validators Verifying Transaction....". I have to narrow down the problem on my side before investigation.

[branciard]

The random mystery is solved :). It works until I use my MAX_AMOUNT_PER_TX limit...

My case is that I use external erc20 so the UI control here for max per tx is bypassed.

But after when validator executeAffirmation the contract control here trigger AmountLimitExceeded event here as expected.

This AmountLimitExceeded event is never treated in the getEvents function. Only AffirmationCompleted event will change the status and set new step. And so It stay 'stuck' on the interface at "Validators Verifying Transaction...." .

I close this issue because the mystery is solved.

Do you think I need to create 2 new issues for robustess UI improvement ?:

1 - keep UI limit controls for external ERC20 too here , because it will failed later with the smart contract AmountLimitExceeded event triggered.

and/or

2 - treat potential AmountLimitExceeded event in the getEvents function. Something like this :

const amountLimitExceededEvents = homeEvents.filter(
        (event) => {
         return event.event === "AmountLimitExceeded" 
})
amountLimitExceededEvents.forEach(event => {
          this.alertStore.setLoading(false)
          this.alertStore.pushError(`cannot be proceed : amountLimitExceeded `+ blabla values here )
          ...
            remove event from list ?.
          ...
})

[akolotov]

@branciard thanks for figuring this out. I think there is no need to create new issues since the bug will not appear as soon as #178 is addressed (seems that it similar
you suggested in the option 1).