Flow-Cli 0.39.3 unable to retrieve transaction

[fyrz]

Problem

Flow-cli crashes when retrieving transactions in json format via cmd-line or runs endless

Steps to Reproduce

Examples: flow transactions get 312741367b158b1c63e39c22cb34026b88334723678d76b7253f06b790b0f911 -n mainnet -o json - crash flow transactions get 16de57b007aa44dee2280231e7490a420f0f1c34b2212f438b74c156636553c8 -n mainnet -o json - endless no return

Context

Blocks from providing tax relevant information.

[devbugging]

I was able to reproduce this problem for those transactions. It looks like the transaction includes some values in the events that cause the issue. Will try to provide a solution soon. Thank you for reporting.

[bluesign]

@sideninja yeah that was my fix I remember the contract ( typeID cadence ) maybe cadence changed something ? it was hacky fix

PS: yeah we fixed for legacy typeID, here it is coming as [TypeID] ( array of TypeIDs) maybe we can get this fixed in Cadence to make it not more monkeypatch.

PS2: Otherwise we need to get all type encoding code from Cadence codebase.

[devbugging]

@bluesign I remember yeah. Will try to include the Cadence team in this.

[fyrz]

Any news on this topic ? @sideninja

[devbugging]

@SupunS do you maybe have some context around this?

[SupunS]

Yeah, this is a problem with the TypeID encoding/decoding.

As you may know, earlier cadence-json format used to encode type-information as a string (say jsoncdc V1), but later it was improved to encode type information as a complete object (let's say V2).

To maintain backward compatibility for the existing/old encoded values/events, the decoder supports both the versions V1 and V2. No problem there.

However, since all new values are encoded using V2, the encoder only supports the new version V2. But seems in the CLI it also tries to encode a Cadence value which was decoded in the older format (V1): https://github.com/onflow/flow-cli/blob/335acdc3cd2f42747dc711ce58cf057a33d21e16/internal/transactions/transactions.go#L121-L124

[SupunS]

I think the existing code at CLI (above) already correctly handles that up to one level. Would just need to make it recursive. I'll see if we can fix it there.

[SupunS]

Well, yeah, to support old behaviour for TypeValues recursively, you would have to copy over lots of code/logic (for all container types) from the old encoder.

Another option is to also support encoding typeIDs in the old format in the new encoder, just like in the decoder, behind a flag.

CC: @turbolent

[bluesign]

@SupunS yeah I made the fix for one level, but rest got complicated, I did not feel comfortable copying that much.

[SupunS]

Can't we print the original payload content, instead of re-encoding here: https://github.com/onflow/flow-cli/blob/923bbe8b91506d319d628b43609cf86eb836156e/internal/transactions/transactions.go#L154

i.e: instead of json.Marshal(prepareEvent(event.Value)), can use event.Payload which already have the json encoded content.

[bluesign]

@SupunS , actually it works, thanks a lot. I didn't know about event.Payload.

PS: made a PR

[bluesign]

flow transactions get 16de57b007aa44dee2280231e7490a420f0f1c34b2212f438b74c156636553c8 -n mainnet -o json - endless no return this one can be related to AN I guess

[fyrz]

@bluesign short question, I do not understand your last comment. Does the pull request solve both problems or only one of the problems ?

[bluesign]

@fyrz I think that transaction somehow does not exist in the AN, so CLI thinks it is just sent and waiting for it to be sealed. But someone from flow team can dig deeper. /cc @sideninja

[fyrz]

@sideninja this issue is not resolved. See for example transaction: e8a51280ae3a3df06263ac5ddb8239f8bb7ae76ed37f59865aa9aa5fa42d83c2

flow transactions get e8a51280ae3a3df06263ac5ddb8239f8bb7ae76ed37f59865aa9aa5fa42d83c2 -n mainnet -o json

This doesn't return. I understood also that @bluesign addressed this issue with his comment.

[devbugging]

@fyrz the crasher was fixed. The issue you are explaining is coming from the fact that the transaction is probably from previous sporks and can't be accessed. That's not a CLI issue. I assume that tho about the tx ID so correct me if I'm wrong.

[fyrz]

@sideninja: Actually no. See for example the transaction fd561db7293c156f702617fce43876409c4b44f83c1de5d89008962fd0d30de3 this one is from September. In the past the client did work for all transactions no matter if a spork happened or not.

The problems started to appear in June with the big update. Since then the client is partly broken when it comes down to JSON retrievable.

Also retrieving these transactions is very important because at least in my country we need to store this information for 10years.

[devbugging]

I see. If the transaction is not super old then it might be a problem with CLI. I just assumed because there are two different issues in this issue. Will reopen and try to resolve next week ok?

[fyrz]

@sideninja thank you.

[devbugging]

Until then you can even use HTTP API to get that transactions by using

https://rest-mainnet.onflow.org/v1/transactions/fd561db7293c156f702617fce43876409c4b44f83c1de5d89008962fd0d30de3

not sure if that helps you tho

[fyrz]

@sideninja thanks for the tip. I was looking into this too. But the content between the client and the REST API is very different. Actually the events and what happened is not listed there. I also didn't find any documentation to retrieve something similar using this API.

[devbugging]

@fyrz oh yeah you can add expand:

https://rest-mainnet.onflow.org/v1/transactions/fd561db7293c156f702617fce43876409c4b44f83c1de5d89008962fd0d30de3?expand=result

[devbugging]

But you have to decode64 the payload of event to get values. Docs on that are not best https://developers.flow.com/http-api/#tag/Transactions/paths/~1transactions~1%7Bid%7D/get

[devbugging]

@fyrz fixed it in https://github.com/onflow/flow-cli/pull/679

[fyrz]

@sideninja can you deploy a new version ?

[devbugging]

@fyrz it is. Let me know if it works ok for you.