mmsqe

Results 60 comments of mmsqe

fixed by https://github.com/crypto-org-chain/cronos/pull/1272

Thanks @andynog, patch works for v0.38.x.

@xloem have you try hex encode the marshalled request? or you can try base64 encoded fee_collector from cronos. ``` curl -s -X GET 'https://rpc.cronos.org/abci_query?path=%22%2Fcosmos.auth.v1beta1.Query%2FModuleAccountByName%22&data=0x0A0D6665655F636F6C6C6563746F72' | jq -r '.result.response.value' CmUKIi9jb3Ntb3MuYXV0aC52MWJldGExLk1vZHVsZUFjY291bnQSPwouCipjcmMxN3hwZnZha20yYW1nOTYyeWxzNmY4NHoza2VsbDhjNWw4OGVrZXIYCBINZmVlX2NvbGxlY3Rvcg== ```

Seems you could try pass these 3 functions as the last options params of NewWS https://github.com/cometbft/cometbft/blob/227ad25ca850d0b92c7310cbfad50d89f29cee43/rpc/jsonrpc/client/ws_client.go#L148-L168

> Hey @mmsqe thanks for the contribution! > > What is the need you have for limiting the max number of messages to broadcast? _Are you hitting block size issues?...

> but we need to keep it backward compatible, right? to avoid breaking existing contracts? yes, but if we add it as a new, we need call both functions? ```...

not sure if we just pass [req.Data](https://github.com/crypto-org-chain/cronos/blob/main/x/cronos/keeper/keeper.go#L320) to contract, not sure how contract handle dynamically since `safeRsp.Responses` could come from query balance or param ``` var safeRes hosttypes.MsgModuleQuerySafe err :=...

seems getting syntax errors by just changing to named interface + type alias

not sure if related to different client, but v0.37.2 seems return expected log from ethermint ``` echo "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"subscribe\",\"params\":[\"tm.event='Tx' AND message.module='evm'\"]}" | websocat -n -t ws://127.0.0.1:26657/websocket | jq .result.data.value.TxResult.result.log "[{\"msg_index\":0,\"events\":[{\"type\":\"message\",\"attributes\":[{\"key\":\"action\",\"value\":\"/ethermint.evm.v1.MsgEthereumTx\"},{\"key\":\"sender\",\"value\":\"ethm12luku6uxehhak02py4rcz65zu0swh7wjun6msa\"}]},{\"type\":\"ethereum_tx\",\"attributes\":[{\"key\":\"amount\",\"value\":\"0\"},{\"key\":\"ethereumTxHash\",\"value\":\"0x541b3b39211c87576068d457c1522909b1af285729e8533e993e7de65867b077\"},{\"key\":\"txIndex\",\"value\":\"0\"},{\"key\":\"txGasUsed\",\"value\":\"616189\"},{\"key\":\"txHash\",\"value\":\"EA1264175496DAD79EDD9441D5949C1A758EED74EACE53AF6D538C7232E351BE\"}]},{\"type\":\"message\",\"attributes\":[{\"key\":\"module\",\"value\":\"evm\"},{\"key\":\"sender\",\"value\":\"0x57f96e6b86cdefdb3d412547816a82e3e0ebf9d2\"},{\"key\":\"txType\",\"value\":\"2\"}]}]}]" ```

> Can we get away with simply replacing `map` with `sync.Map`? since priorityCounts, priorityScores, priorityIndex, element from Next need lock together, it's harder to go wrong when wrap to handle...