Skip to content

[Version-unspecific] Debug logs only for expected ParseMemo errors

[Version-unspecific]

In the spirit of !2766 (merged), this is intended to hide by default certain error logs which look alarming but do not represent problems.

Specifically, this was prompted by logs for inbound
06A259064ED27533CC9B37FCFDE83DDD280512502B400FEBEBE0AADA75D8A199
, for which both inbound and outbound had no problems. These Bifrost logs prompted concern:

{"level":"error","service":"bifrost","module":"observer","error":"address format not supported: te","time":"2023-02-26T02:08:53Z","caller":"/app/bifrost/observer/observe.go:312","message":"Unable to parse memo: =:BNB.BNB:bnb1qj5dk4y6dy4vk0u8hy3f6d6qdyvsysgja8rpcy:966091:te:0"}

{"level":"error","service":"bifrost","module":"binance","error":"address format not supported: te","time":"2023-02-26T02:08:53Z","caller":"/app/bifrost/pkg/chainclients/binance/binance.go:627","message":"fail to parse memo: =:BNB.BNB:bnb1qj5dk4y6dy4vk0u8hy3f6d6qdyvsysgja8rpcy:966091:te:0"}

The observe.go error was not a problem because after the ParseMemo error from the affiliate THORName the code manually interpreted the destination in case it was a THORName.

The binance.go error was from a section of code that checks whether a transaction is an outbound appropriate for calling SetSigned. ParseMemo fails whenever considering an inbound with a THORName in the memo, but returning here
(as it is not a valid outbound memo, and even if parsed would have been returned for not being an outbound)
is normal/desirable behaviour.

For context, my impression is that ParseMemoWithTHORNames is not used because it needs a Keeper argument, whereas observe.go for instance manually resolves a THORName with name, _ := bridge.GetTHORName(raw) .

At present I have not changed the smartcontract_log_parser instances of 'fail to parse memo' (/ethereum/ or /shared/evm/)
as they specify with switch and case transferOutEvent / transferAllowanceEvent / vaultTransferEvent / transferOutAndCallEvent conditionals,
for which my current impression is that ParseMemo is expected to never fail (and attention always appropriate if there is an error).

Edited by Multipartite

Merge request reports