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

Extend upgrade contract from 30 to 60 days #1129

Merged
merged 1 commit into from
Oct 23, 2023

Conversation

sisuresh
Copy link
Contributor

What

Leave enough time for validators to inspect upgrades. It's important to note that the initial MAXIMUM_ENTRY_LIFETIME in core is 31 days, so that should be increased if this PR is accepted.

@sisuresh sisuresh requested a review from a team as a code owner October 23, 2023 17:22
@sisuresh sisuresh changed the title Extend upgrade contract from 303 to 60 days Extend upgrade contract from 30 to 60 days Oct 23, 2023
Copy link
Contributor

@dmkozh dmkozh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What will happen if we don't update the core expiration limit? Maybe we should clamp the value with ledger max expiration?

@sisuresh
Copy link
Contributor Author

What will happen if we don't update the core expiration limit? Maybe we should clamp the value with ledger max expiration?

It'll error here -

if new_live_until > host.max_live_until_ledger()? {
. Clamping silently doesn't sound safe or good UX to me. If the transaction was accepted, I'd expect the lifetime to be extended to what I requested.

@dmkozh
Copy link
Contributor

dmkozh commented Oct 23, 2023

Clamping silently doesn't sound safe or good UX to me. If the transaction was accepted, I'd expect the lifetime to be extended to what I requested

Yeah, I recall we've decided we won't do clamping in the host function itself. But I think clamping makes sense for the contract to do in order to not be bricked (after all, lifetime extension is not critical for the contract business logic and can be updated externally). So I would probably do that here just as a best practice (or maybe bump using the network setting?). I don't have too strong opinion here though.

@sisuresh
Copy link
Contributor Author

Clamping silently doesn't sound safe or good UX to me. If the transaction was accepted, I'd expect the lifetime to be extended to what I requested

Yeah, I recall we've decided we won't do clamping in the host function itself. But I think clamping makes sense for the contract to do in order to not be bricked (after all, lifetime extension is not critical for the contract business logic and can be updated externally). So I would probably do that here just as a best practice (or maybe bump using the network setting?). I don't have too strong opinion here though.

Ah while that isn't a bad idea, I don't think it's necessary here because we invoke this contract in a core test case with the minimum settings, so we'd find out if the contract was bricked on the env bump.

@sisuresh sisuresh added this pull request to the merge queue Oct 23, 2023
Merged via the queue into stellar:main with commit be0aff3 Oct 23, 2023
10 checks passed
@sisuresh sisuresh deleted the write-bytes-lifetime branch October 23, 2023 23:34
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.

2 participants