Skip to content

StorageHub v0.2.8

Choose a tag to compare

View all tags
@ffarall ffarall released this 29 Dec 14:53
· 6 commits to release/v0.2 since this release
v0.2.8
c7b5a8d
This commit was signed with the committer’s verified signature.
ffarall Facundo Farall
GPG key ID: 181949FEE18352BC
Verified
Learn about vigilant mode.

StorageHub v0.2.8

Summary

StorageHub v0.2.8 is a small, non‑breaking patch release focused on improving observability and tightening concurrency in the client. It adds clearer logging around file and bucket operations (including consistent formatting for file keys and bucket IDs) and narrows the scope of read/write locks around forest and file storage, reducing the risk of long‑held locks during network I/O while preserving existing behaviour.

Components

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

Changes since last tag

Base: 9dcf64a19743e48854504d9251070392f729d371

  • Highlights:
    • Client observability – block and forest processing: added log statements at the end of block processing and at the start of applying forest root changes, making it easier to trace the lifecycle of block‑driven state updates in the client (client/src/tasks).
    • Consistent logging of identifiers: unified the logging style for file keys and bucket IDs across MSP/BSP and fisherman tasks, formatting them consistently as hex identifiers (for example file key [0x…] and bucket [0x…]) to simplify searching and correlating logs across services.
    • Safer lock usage in client tasks: refactored several MSP/BSP client tasks to narrow the lifetime of file‑ and forest‑storage read/write locks, ensuring that heavy work (such as proof generation and network I/O) happens outside of locked sections, which reduces contention and helps avoid deadlocks while preserving existing semantics.
  • Full diff: https://github.com/Moonsong-Labs/storage-hub/compare/9dcf64a19743e48854504d9251070392f729d371...c7b5a8d53b80f2521eadc7feb5ba6cda1f76f198
  • PRs included:
    • None. All changes in this range were committed directly to the release branch without associated GitHub pull requests. The relevant commits are:
      • 56b0ed48dd1bb7e901d28d9b88c29e91b5a301f3 – add logs at the end of block processing.
      • e70c0dbd0d3b065647dd440d84e98ffed9ae5d19 – unify logging style of file keys and bucket IDs.
      • 68c2a02b14a881a33e0e0fa4ffe7daeb59fd15c7 – add log at the beginning of applying forest root changes.
      • c7b5a8d53b80f2521eadc7feb5ba6cda1f76f198 – narrow the scope of read/write locks in client file/forest storage code.

Migrations

RocksDB (File Storage)

  • Changes:
    • No new schema changes.
  • Action required:
    • None.

RocksDB (Forest Storage)

  • Changes:
    • No new schema changes.
  • Action required:
    • None.

RocksDB (State store)

  • Changes:
    • No schema changes that require migration.
  • Action required:
    • None.

Indexer DB (Postgres)

  • Migrations:
    • No new indexer migrations were introduced in this release; the migration set is unchanged from v0.2.0.
  • How to apply: The indexer service runs migrations automatically on startup. Alternatively run diesel migration run.

Pending extrinsics DB (Postgres)

  • Migrations:
    • No new migrations; the pending‑extrinsics schema introduced in v0.2.0 remains unchanged.
  • How to apply: The Blockchain Service runs migrations automatically on startup. Alternatively run diesel migration run.

⚠️ Breaking Changes ⚠️

None. Upgrading from the previous release should be seamless. All PRs included in this release are labelled not-breaking and do not introduce breaking changes to public APIs, runtime storage layouts, or configuration surfaces.

Runtime

  • Upgrades (spec_version): parachain and solochain-evm remain at spec_version 1; no runtime upgrades were made in this release.
  • Migrations: No new runtime storage migrations were added.
  • Constants changed: None that require operator action.
  • Scripts to run: None specific to this release.

Client

  • Behaviour changes:
    • Improved logging for block and forest processing: additional logs now mark the end of block processing and the start of applying forest root changes, providing clearer visibility into when client‑side state transitions driven by blocks actually complete.
    • Consistent identifier formatting: logs across MSP, BSP, and fisherman tasks now consistently format file keys and bucket IDs as hex values in brackets, which helps correlate events across components (for example NSP/BSP upload/download handling, move‑bucket flows, and batch deletions).
    • More precise lock scoping: several client tasks (including upload, download, move bucket, delete bucket/file, and batch deletion handlers) now acquire read/write locks on file and forest storage only for the minimal duration necessary, releasing them before running any network I/O or heavier computation. This reduces contention and the likelihood of deadlocks without changing external behaviour.
  • Initialisation changes:
    • None. Existing client configuration (including database URLs and network settings) remains valid and there are no new CLI flags or config fields introduced by this release.

Backend

  • Behaviour changes:
    • None in this release. Backend behaviour, HTTP APIs, and configuration remain as described in v0.2.0.
  • Initialisation changes:
    • None. Existing backend_config.toml values and deployment scripts continue to apply unchanged.

SDK

  • Behaviour changes:
    • None in this release. The SDK packages (@storagehub-sdk/core, @storagehub-sdk/msp-client) remain at v0.3.3, with no API or typing changes compared to v0.2.0.
  • Initialisation changes:
    • None. Existing SDK initialisation and configuration code continues to work without modification.

Versions

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

Compatibility

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

Upgrade Guide

None. Upgrading from the previous release should be seamless. All PRs included in this release are labelled not-breaking and do not introduce breaking changes to public APIs, runtime storage layouts, or configuration surfaces.

Assets 2
Loading