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

Modify get/put current source to take in just a transaction ID #5036

Merged
merged 1 commit into from
Jan 31, 2025

Conversation

cronokirby
Copy link
Contributor

Right now this is only ever a transaction id, and for LQT work, we need to be able to just use a transaction ID, so it's better to reify that, and change a few uses to wrap it in a source, versus having to unwrap it, introducing a spurious failure case

Smoke tests should be sufficient.

Checklist before requesting a review

  • I have added guiding text to explain how a reviewer should test these changes.

  • If this code contains consensus-breaking changes, I have added the "consensus-breaking" label. Otherwise, I declare my belief that there are not consensus-breaking changes, for the following reason:

    This state is always initialized before being read, so there's no issue in changing the type we store under this state key ; reviewers should double check this.

@conorsch
Copy link
Contributor

Needs more work for CI to pass. Should this change be targeting the LQT feature branch? It's currently targeting main, which doesn't seem like the worst idea, but we'd have to rebase.

@cronokirby
Copy link
Contributor Author

Yeah, targetting main was intentional ; would be good occasion to rebase protocol/lqt_branch, which we want to do from time to time anyways

@hdevalence
Copy link
Contributor

do we need to apply this to main? it shouldn't have consensus breaking effects but it also doesn't seem like there's a need to merge it in there, vs bundling it with known breaking changes ?

@cronokirby cronokirby force-pushed the transaction-id-as-ambient-source branch from 2bf0e2c to a0edde9 Compare January 31, 2025 19:38
@conorsch
Copy link
Contributor

I agree this should target the LQT branch, out of conservativism. However, post-merge, we should indeed rebase.

Verified

This commit was signed with the committer’s verified signature.
AkihiroSuda Akihiro Suda
Right now this is only ever a transaction id, and for LQT work, we need
to be able to just use a transaction ID, so it's better to reify that,
and change a few uses to wrap it in a source, versus having to unwrap it,
introducing a spurious failure case
@cronokirby cronokirby force-pushed the transaction-id-as-ambient-source branch from a0edde9 to bb50e69 Compare January 31, 2025 19:55
@cronokirby cronokirby changed the base branch from main to protocol/lqt_branch January 31, 2025 19:56
@cronokirby cronokirby requested review from erwanor and hdevalence and removed request for erwanor January 31, 2025 20:20
@erwanor
Copy link
Member

erwanor commented Jan 31, 2025

LGTM. Let's just bundle this with the protocol breaking changes. It shouldn't be CB, but it touches storage and there's no real upside in getting it into main.

@conorsch conorsch merged commit 91e4783 into protocol/lqt_branch Jan 31, 2025
15 checks passed
@conorsch conorsch deleted the transaction-id-as-ambient-source branch January 31, 2025 22:26
conorsch pushed a commit that referenced this pull request Jan 31, 2025
Right now this is only ever a transaction id, and for LQT work, we need
to be able to just use a transaction ID, so it's better to reify that,
and change a few uses to wrap it in a source, versus having to unwrap
it, introducing a spurious failure case

Smoke tests should be sufficient.

## Checklist before requesting a review

- [x] I have added guiding text to explain how a reviewer should test
these changes.

- [x] If this code contains consensus-breaking changes, I have added the
"consensus-breaking" label. Otherwise, I declare my belief that there
are not consensus-breaking changes, for the following reason:

> This state is always initialized before being read, so there's no
issue in changing the type we store under this state key ; reviewers
should double check this.
@conorsch
Copy link
Contributor

However, post-merge, we should indeed rebase.

Done. Latest sha1 on protocol/lqt_branch is 103b2a12c00ae60aba48f447b762108aa31ce390.

conorsch pushed a commit that referenced this pull request Feb 4, 2025
Right now this is only ever a transaction id, and for LQT work, we need
to be able to just use a transaction ID, so it's better to reify that,
and change a few uses to wrap it in a source, versus having to unwrap
it, introducing a spurious failure case

Smoke tests should be sufficient.

## Checklist before requesting a review

- [x] I have added guiding text to explain how a reviewer should test
these changes.

- [x] If this code contains consensus-breaking changes, I have added the
"consensus-breaking" label. Otherwise, I declare my belief that there
are not consensus-breaking changes, for the following reason:

> This state is always initialized before being read, so there's no
issue in changing the type we store under this state key ; reviewers
should double check this.
conorsch pushed a commit that referenced this pull request Feb 5, 2025
Right now this is only ever a transaction id, and for LQT work, we need
to be able to just use a transaction ID, so it's better to reify that,
and change a few uses to wrap it in a source, versus having to unwrap
it, introducing a spurious failure case

Smoke tests should be sufficient.

## Checklist before requesting a review

- [x] I have added guiding text to explain how a reviewer should test
these changes.

- [x] If this code contains consensus-breaking changes, I have added the
"consensus-breaking" label. Otherwise, I declare my belief that there
are not consensus-breaking changes, for the following reason:

> This state is always initialized before being read, so there's no
issue in changing the type we store under this state key ; reviewers
should double check this.
conorsch pushed a commit that referenced this pull request Feb 5, 2025
Right now this is only ever a transaction id, and for LQT work, we need
to be able to just use a transaction ID, so it's better to reify that,
and change a few uses to wrap it in a source, versus having to unwrap
it, introducing a spurious failure case

Smoke tests should be sufficient.

## Checklist before requesting a review

- [x] I have added guiding text to explain how a reviewer should test
these changes.

- [x] If this code contains consensus-breaking changes, I have added the
"consensus-breaking" label. Otherwise, I declare my belief that there
are not consensus-breaking changes, for the following reason:

> This state is always initialized before being read, so there's no
issue in changing the type we store under this state key ; reviewers
should double check this.
conorsch pushed a commit that referenced this pull request Feb 14, 2025
Right now this is only ever a transaction id, and for LQT work, we need
to be able to just use a transaction ID, so it's better to reify that,
and change a few uses to wrap it in a source, versus having to unwrap
it, introducing a spurious failure case

Smoke tests should be sufficient.

## Checklist before requesting a review

- [x] I have added guiding text to explain how a reviewer should test
these changes.

- [x] If this code contains consensus-breaking changes, I have added the
"consensus-breaking" label. Otherwise, I declare my belief that there
are not consensus-breaking changes, for the following reason:

> This state is always initialized before being read, so there's no
issue in changing the type we store under this state key ; reviewers
should double check this.
conorsch pushed a commit that referenced this pull request Feb 21, 2025
Right now this is only ever a transaction id, and for LQT work, we need
to be able to just use a transaction ID, so it's better to reify that,
and change a few uses to wrap it in a source, versus having to unwrap
it, introducing a spurious failure case

Smoke tests should be sufficient.

## Checklist before requesting a review

- [x] I have added guiding text to explain how a reviewer should test
these changes.

- [x] If this code contains consensus-breaking changes, I have added the
"consensus-breaking" label. Otherwise, I declare my belief that there
are not consensus-breaking changes, for the following reason:

> This state is always initialized before being read, so there's no
issue in changing the type we store under this state key ; reviewers
should double check this.
cronokirby added a commit that referenced this pull request Feb 27, 2025
Right now this is only ever a transaction id, and for LQT work, we need
to be able to just use a transaction ID, so it's better to reify that,
and change a few uses to wrap it in a source, versus having to unwrap
it, introducing a spurious failure case

Smoke tests should be sufficient.

## Checklist before requesting a review

- [x] I have added guiding text to explain how a reviewer should test
these changes.

- [x] If this code contains consensus-breaking changes, I have added the
"consensus-breaking" label. Otherwise, I declare my belief that there
are not consensus-breaking changes, for the following reason:

> This state is always initialized before being read, so there's no
issue in changing the type we store under this state key ; reviewers
should double check this.
conorsch pushed a commit that referenced this pull request Mar 18, 2025
Right now this is only ever a transaction id, and for LQT work, we need
to be able to just use a transaction ID, so it's better to reify that,
and change a few uses to wrap it in a source, versus having to unwrap
it, introducing a spurious failure case

Smoke tests should be sufficient.

## Checklist before requesting a review

- [x] I have added guiding text to explain how a reviewer should test
these changes.

- [x] If this code contains consensus-breaking changes, I have added the
"consensus-breaking" label. Otherwise, I declare my belief that there
are not consensus-breaking changes, for the following reason:

> This state is always initialized before being read, so there's no
issue in changing the type we store under this state key ; reviewers
should double check this.
conorsch pushed a commit that referenced this pull request Mar 24, 2025
Right now this is only ever a transaction id, and for LQT work, we need
to be able to just use a transaction ID, so it's better to reify that,
and change a few uses to wrap it in a source, versus having to unwrap
it, introducing a spurious failure case

Smoke tests should be sufficient.

## Checklist before requesting a review

- [x] I have added guiding text to explain how a reviewer should test
these changes.

- [x] If this code contains consensus-breaking changes, I have added the
"consensus-breaking" label. Otherwise, I declare my belief that there
are not consensus-breaking changes, for the following reason:

> This state is always initialized before being read, so there's no
issue in changing the type we store under this state key ; reviewers
should double check this.
cronokirby added a commit that referenced this pull request Mar 28, 2025
Right now this is only ever a transaction id, and for LQT work, we need
to be able to just use a transaction ID, so it's better to reify that,
and change a few uses to wrap it in a source, versus having to unwrap
it, introducing a spurious failure case

Smoke tests should be sufficient.

## Checklist before requesting a review

- [x] I have added guiding text to explain how a reviewer should test
these changes.

- [x] If this code contains consensus-breaking changes, I have added the
"consensus-breaking" label. Otherwise, I declare my belief that there
are not consensus-breaking changes, for the following reason:

> This state is always initialized before being read, so there's no
issue in changing the type we store under this state key ; reviewers
should double check this.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants