Skip to content

feat(storage): extend persistent storage TTL on every write#460

Open
devEunicee wants to merge 1 commit into
PrincessnJoy:mainfrom
devEunicee:feature/294-persistent-storage-ttl-extension
Open

feat(storage): extend persistent storage TTL on every write#460
devEunicee wants to merge 1 commit into
PrincessnJoy:mainfrom
devEunicee:feature/294-persistent-storage-ttl-extension

Conversation

@devEunicee

Copy link
Copy Markdown
Contributor

Summary

Closes #294

Soroban persistent storage entries expire if their TTL reaches zero. This PR bumps the TTL on every write to persistent storage so proposal and vote data survives the full proposal lifecycle.

Changes

  • contracts/governance/src/storage.rs — Added TTL constants and extend_ttl calls on every set_* persistent accessor:
    • PROPOSAL_TTL_LEDGERS = 518_400 (~30 days at 5 s/ledger) applied to Proposal, HasVoted, VoteRecord keys
    • COOLDOWN_TTL_LEDGERS = 120_960 (~7 days) applied to LastProposal key
  • docs/storage.md — Added Storage TTL Extension section documenting TTL values, rationale, and assumptions

Testing

Existing test suite is unaffected. extend_ttl is a no-op in test environments unless ledger sequence is explicitly advanced past the TTL.

…nJoy#294)

- Add PROPOSAL_TTL_LEDGERS (518400 ~30d) and VOTE_TTL_LEDGERS for
  proposal/vote/has-voted keys
- Add COOLDOWN_TTL_LEDGERS (120960 ~7d) for LastProposal cooldown key
- Call extend_ttl on every persistent set_* so data survives the full
  proposal lifecycle without manual bumping
- Document TTL assumptions and constants in docs/storage.md

Closes PrincessnJoy#294
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.

Implement persistent storage TTL extension for proposal records

1 participant