Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TransactionId empty if SignedTransaction initialized by constructor @JsonCreator #424

Open
Reguzzoni opened this issue Nov 15, 2022 · 2 comments
Labels
bug Something isn't working Team Lamprey

Comments

@Reguzzoni
Copy link
Contributor

Problem

The SignedTransaction created by deserialization JSON (@JSONCreator) doesn't fill the attribute transactionId.
https://github.com/algorand/java-algorand-sdk/blob/develop/src/main/java/com/algorand/algosdk/transaction/SignedTransaction.java#L80

So with Atomic Composer if I put a TxnSigner as a external request that works with deserialization of SignedTransaction, It will not work cause the transactionId is emtpy.
https://github.com/algorand/java-algorand-sdk/blob/develop/src/main/java/com/algorand/algosdk/transaction/AtomicTransactionComposer.java#L188

Solution

We could add the transactionId into the constructor through@JSONCreator or other options proposed by barnji:
instead of using the txid directly from signed transaction object, use signedtransaction.tx.getTxId() or w/e its called in the atc.
it'd be redundant hashing possibly but safer in the case of a enc/dec stxn

Dependencies

No dependencies

Urgency

Low Urgency, easy to implement a workaround

@winder
Copy link
Contributor

winder commented May 23, 2023

I'm not very familiar with the ATC, but from what you described I think another solution would be to call the get transaction ID function instead of assuming the field is filled in.

A small example program would help me understand the exact problem.

@winder winder added the bug Something isn't working label Jun 8, 2023
@winder
Copy link
Contributor

winder commented Jun 8, 2023

This is probably because the txid is not part of the canonical representation. We exclude it during serialization and need to recompute it during deserialization.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working Team Lamprey
Projects
None yet
Development

No branches or pull requests

2 participants