You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Not sure if this affects others apart from myself but I believe it will be useful in the long run.
I am working on a generic cosmos indexing solution and when it comes to balance tracking, the easiest and most efficient way is to use the coin_spent/coin_received events as triggered on addCoins and subUnlockedCoins which are called on all exposed BankKeeper methods (incl. MintCoins). Listening for events of type types.EventTypeTransfer is not appropriate as these are not emitted on coin minting cases.
The problem is that the events emitted for sendManyCoins are of the same type as the ones for standard transfers, i.e. types.EventTypeTransfer which as explained above are problematic as the only balance tracking tool.
Not entirely certain how this can be improved. Perhaps an additional attribute to the event to clarify the triggering origin?
Thanks,
The text was updated successfully, but these errors were encountered:
Hello,
Not sure if this affects others apart from myself but I believe it will be useful in the long run.
I am working on a generic cosmos indexing solution and when it comes to balance tracking, the easiest and most efficient way is to use the
coin_spent
/coin_received
events as triggered onaddCoins
andsubUnlockedCoins
which are called on all exposed BankKeeper methods (incl.MintCoins
). Listening for events of typetypes.EventTypeTransfer
is not appropriate as these are not emitted on coin minting cases.The change here: https://github.com/osmosis-labs/cosmos-sdk/blob/osmo/v0.47.5/x/bank/keeper/send.go#L290-L307 to the non-event emitting
addCoinsImproved
is perfectly understandable from a performance standpoint for epoch sends handling but completely breaks the indexing solution above.The problem is that the events emitted for sendManyCoins are of the same type as the ones for standard transfers, i.e. types.EventTypeTransfer which as explained above are problematic as the only balance tracking tool.
Not entirely certain how this can be improved. Perhaps an additional attribute to the event to clarify the triggering origin?
Thanks,
The text was updated successfully, but these errors were encountered: