Skip to content
New issue

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

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

Already on GitHub? # to your account

Technical Debt Tracker #145

Closed
6 tasks done
AdityaSripal opened this issue Apr 28, 2021 · 4 comments
Closed
6 tasks done

Technical Debt Tracker #145

AdityaSripal opened this issue Apr 28, 2021 · 4 comments

Comments

@AdityaSripal
Copy link
Member

AdityaSripal commented Apr 28, 2021

This issue is a tracker for technical debt accumulated after IBC 1.0 for the purpose of maintaining backward compatibility.

@colin-axner
Copy link
Contributor

tendermint#6403 may influence which attribute should be deprecated between packet_data and packet_data_hex. We can discuss with relayers which is preferred when the time comes

@crodriguezvega
Copy link
Contributor

All the PRs mentioned above haven been merged and I believe the upgrade keeper is already used to set client/consensus states. Thus I will close the issue now.

@colin-axner
Copy link
Contributor

colin-axner commented Mar 30, 2023

I believe the upgrade keeper is already used to set client/consensus states.

This is correct. The original issue is a bit hard to follow, but the intention was to note technical debt, so the fact that the client/consensus states being set by the upgrade keeper is actually a problem. Ideally they would exist under the client keeper.

I think a couple of the other issues mentioned are not addressed:

  • frozen height is still maintained in the client state (it should be a boolean)
  • duplicate event emission for packet_data is still maintained (should be removed)
  • Indirect Iteration Keys needed for efficient iteration while not breaking ICS-24 paths which are inefficient for iteration (we should upgrade connections to allow for efficient iteration of consensus keys, thus making the indirect iteration keys useless)

@colin-axner
Copy link
Contributor

I think we should actually move this issue to a document. I do think it is useful to document areas of the code which have been deprecated and should be fixed/removed when possible

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants