Update transaction ID shown to the user

[vadaynujra]

Context

The current transaction ID is a SEP24 generated ID and isn't captured in the storage file.

User Story

As a developer, I want to easily identify and debug transactions in the dump file when users share the transaction ID they receive for unsuccessful transactions.

Requirement

• Instead of displaying the SEP24 id, show the squidRouterReceiverId instead
  • however, don't show the complete id, but only the first 12 hexadecimal digits in the form dddd-dddd-dddd (where d is one digit)

[TorstenStueber]

@vadaynujra I updated the description. We already store the complete id in the sheet so there is no work required for additional data dumping.

[prayagd]

Hey team! Please add your planning poker estimate with Zenhub @b-yap @bogdanS98 @ebma @gianfra-t @TorstenStueber

[prayagd]

Remove it from success page and keep it on unsuccess page

[prayagd]

@vadaynujra as discussed the squidRouterReceiverId is of no use to the end user, we would need to define what exactly to be shown here

@TorstenStueber i saw after the bridge(polygon to moonbeam) is completed there is txn hash printed in the console but didnt find that hash in the dumping sheet. IMO showing that hash to the end user would be somewhat helpful

[ebma]

the squidRouterReceiverId is of no use to the end user, we would need to define what exactly to be shown here

Maybe we should discuss this again and with more context. What exactly is the need for this change? Why would we want to show a different ID to the user? Is it a) to be able to assist with debugging if the user approaches us and tells us the exact ID shown to them on the error page or b) the user is able to investigate the issue by themselves? I understood it's about a) and thus, showing the squidRouterReceiverId would be fine as it helps us internally.

[TorstenStueber]

Yes, I totally agree with @ebma, that is also my understanding. We also don't link to explorers that show any of the many other transactions, so why do it for this very first step of the flow?

[ebma]

@pendulum-chain/product we did not find an agreement here. Please elaborate on what this identifier is for so we can judge whether it's really needed or how it should look to achieve what you want to gain from it.

[vadaynujra]

I consider this a Developer user story, to improve / simplify debugging internally. Based on that let's go with the suggestion of squidrouterreceiverID which I see is already updated in the description. Added the user story.

[vadaynujra]

@ebma with the above solution suggestion, how would we debug transactions where the user is sent to the unsuccessful screen without signing both transactions?

[TorstenStueber]

We create this id already at the moment the user starts the anchor flow. Failures can't happen before anyway. This means that we will always have the id available whenever the failure screen is shown.