Skip to content

fix(task-registry): use persistent storage for tasks instead of instance - #11

Merged
cybermax4200 merged 1 commit into
ecotask-network:mainfrom
cyberdocs120:fix/task-registry-persistent-storage
Jul 13, 2026
Merged

fix(task-registry): use persistent storage for tasks instead of instance#11
cybermax4200 merged 1 commit into
ecotask-network:mainfrom
cyberdocs120:fix/task-registry-persistent-storage

Conversation

@cyberdocs120

Copy link
Copy Markdown
Contributor

Problem
Tasks were stored in e.storage().instance(), which shares a single TTL across all entries. As task count grows, instance storage bloats and risks hitting ledger size limits.

Solution
Migrated write_task, read_task, push_creator_task, and read_creator_tasks to e.storage().persistent(). Each task now gets its own ledger entry with an independent TTL, matching the pattern already used for Completion entries.

Changes

  • storage.rs: 4 functions switched from instance() to persistent()
  • registry.rs: Added test_task_survives_ledger_advancement — creates a task, completes it, advances the ledger to sequence 5000, then verifies all data remains readable
  • Updated test snapshots for persistent storage entries

All 18 tests pass.

Closes #1

Migrate write_task, read_task, push_creator_task, and read_creator_tasks
from e.storage().instance() to e.storage().persistent() so each task gets
its own ledger entry with an independent TTL. This prevents instance
storage bloat as the number of tasks grows and matches the pattern already
used for Completion entries.

Add test_task_survives_ledger_advancement to verify task data, completion
status, and creator task lists remain readable after advancing the ledger
past instance storage TTL.

Closes ecotask-network#1
@cybermax4200
cybermax4200 merged commit 0bfb7b1 into ecotask-network:main Jul 13, 2026
1 check passed
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.

task-registry: Use persistent storage for tasks instead of instance

2 participants