StorageHub v0.1.5
StorageHub v0.1.5
Summary
StorageHub patch that fixes an issue with the backend when uploading freshly-requested files.
Components
- Client code: v0.1.0
- Pallets code: v0.1.0
- Runtime code: v0.1.0 (spec_name/spec_version: parachain 1, solochain-evm 1)
- SH Backend Docker image: v0.1.1 (image: ghcr.io/Moonsong-Labs/storage-hub-msp-backend:v0.1.5)
- SH SDK (npm): v0.3.2
- types-bundle: v0.2.7
- api-augment: v0.2.9
Changes since last tag
Base commit: 18a562a
- Highlights:
- Full diff: 18a562a...b7e6082
Runtime
- Upgrades (spec_version): parachain and solochain-evm remain at spec_version 1.
- Migrations: No runtime storage migrations detected.
- Constants changed: None requiring operator action.
- Scripts to run: None.
Client
- Behaviour changes: None
Backend
- Behaviour changes:
- Previously, when uploading a new file, the backend checked if the user had permissions to do so by getting the file information from the indexer's DB to check if the user is the owner of said file. This had an issue where recently issued storage requests that weren't finalised yet are not present in the indexer DB, which meant the query failed and the backend returned an error and did not proceed with the upload.
- With the new logic, the backend checks if the user has permissions to upload a file by checking if it's the owner of the bucket where the file is being uploaded to. This still has the same issue when the bucket was created recently and the extrinsic doing so was not finalised yet, but this is a good-enough solution until we implement way of directly checking this on-chain.
Versions
- Polkadot SDK: polkadot-stable2412-6
- Rust: 1.87 (from rust-toolchain.toml)
Compatibility
- SH Backend v0.1.1 → compatible with pallets/runtime v0.1.0 and client v0.1.0.
- SDK v0.3.2 → compatible with backend v0.1.1, client v0.1.0, and pallets/runtime v0.1.0.