StorageHub v0.2.4

Summary

StorageHub v0.2.4 includes a hotfix for how the indexer handles the is_in_bucket field of files, which is the field used by both the fisherman and the indexer service to check if a file is being stored in a bucket currently. Previously, new storage requests defaulted to false for this field, but since storage requests can be created for files that are already stored in a bucket, what we do now is check if the file is in a bucket and set is_in_bucket appropiately.

Components

• Client code: v0.2.4
• Pallets code: v0.2.4
• Runtime code: v0.2.4 (spec_name/spec_version: parachain 1, solochain-evm 1)
• SH Backend Docker image: v0.2.4 (image: ghcr.io/<org>/storage-hub-msp-backend:v0.2.3)
• SH SDK (npm): v0.3.4 (@storagehub-sdk/core, @storagehub-sdk/msp-client)
• types-bundle/api-augment (npm): @storagehub/types-bundle v0.2.8, @storagehub/api-augment v0.2.11

Changes since last tag

Base: 527f303055e6ac136db4d6ca373ecc8fd6feeec6

• Highlights:
  • Fix critical issue with indexer: the indexer will now appropiately populate the is_in_bucket field for new file records created, avoiding inconsistencies and possible issues during deletion.
• Full diff: 527f303...0a076dc
• PRs included:
  • fix: 🚑 make it so is_in_bucket is consistent across same file key records (#598)

⚠️ Breaking Changes ⚠️

• #598: There's a new migration to run that makes existing is_in_bucket fields consistent across file records for identical file keys.

Client/Indexer

• Behaviour changes:
  • Keep is_in_bucket field consistent across a file key: The indexer now correctly sets the initial is_in_bucket status for a new file record when creating it. Updates to that field are done across a file key and not for one specific file record.

Versions

• Polkadot SDK: polkadot-stable2412-6
• Rust: 1.87 (from rust-toolchain.toml)

Compatibility

• SH Backend v0.2.4 → compatible with pallets/runtime v0.2.4 and client v0.2.4 (all built from this release).
• SDK v0.3.4 → compatible with backend v0.2.4, client v0.2.4, and pallets/runtime v0.2.4.

Upgrade Guide

• #598 – running the new indexer DB migration:

There's a new migration for the indexer DB that must be executed for all existing DBs.

• Who is affected

  • Indexer node runners since they'll have to run the new migration

• Changes required

  • Indexer DB: If you are running an indexer, you must run the new migration over your existing indexer DB.

  • Suggested code changes: None.