Feature/bucket label 1354

[giurgiur99]

Fixes oceanprotocol/ocean-node#1354

Changes proposed in this PR:

• Update bucket label + tests

[claude]

Claude Code Review

This repository is configured for manual code reviews. Comment @claude review to trigger a review and subscribe this PR to future pushes, or @claude review once for a one-time review.

_{Tip: disable this comment in your organization's Code Review settings.}

[greptile-apps]

Greptile Summary

This PR adds bucket label support to the Ocean.js persistent storage API: labels can now be set at creation time and updated via a new updatePersistentStorageBucket method exposed through both HttpProvider (PATCH) and P2pProvider (P2P command).

• Types: PersistentStorageCreateBucketRequest gains an optional label?: string, PersistentStorageBucket gains label?: string | null, and a new PersistentStorageUpdateBucketResponse interface is introduced.
• Providers: BaseProvider, HttpProvider, and P2pProvider all receive the new updatePersistentStorageBucket method; the private getPersistentStorageSignaturePayload helper in P2pProvider is removed and replaced by the already-existing getSignedCommandParams, making all persistent storage P2P calls consistent.
• Tests: A new integration test creates a labelled bucket, renames it, and verifies the rename is reflected in the bucket list.

Confidence Score: 5/5

Safe to merge — the new update endpoint and label fields follow the same patterns as existing persistent storage operations and introduce no breaking changes.

The change is additive: a new optional field on existing types, a new PATCH endpoint, and a new P2P command. Both transport implementations mirror the structure of adjacent persistent storage methods. The removal of getPersistentStorageSignaturePayload aligns createPersistentStorageBucket with every other P2P storage method that already called getSignedCommandParams directly, so the refactor is safe. The only open questions were already surfaced in earlier review rounds.

No files require special attention beyond what was already discussed in prior review threads.

Important Files Changed

Filename	Overview
src/@types/File.ts	Adds optional label to create-request and bucket types, and new PersistentStorageUpdateBucketResponse with non-optional label: string
src/@types/Provider.ts	Adds PERSISTENT_STORAGE_UPDATE_BUCKET command constant, straightforward addition
src/services/providers/BaseProvider.ts	Adds updatePersistentStorageBucket public method and label field to create-bucket return type; delegates correctly to the impl
src/services/providers/HttpProvider.ts	Adds HTTP PATCH implementation for updatePersistentStorageBucket; auth params go into query string while label goes into request body, consistent with existing methods
src/services/providers/P2pProvider.ts	Removes private getPersistentStorageSignaturePayload helper (replaced by direct getSignedCommandParams calls, consistent with all other P2P storage methods) and adds updatePersistentStorageBucket
test/integration/Provider.test.ts	Adds integration test covering label creation and rename; depends on server echoing label in the create response, which is not guaranteed by the current type
.github/CODEOWNERS	Adds @dnsi0 as a code owner, no issues

Sequence Diagram

sequenceDiagram
    participant Client
    participant BaseProvider
    participant HttpProvider
    participant P2pProvider
    participant Node as Ocean Node

    Client->>BaseProvider: updatePersistentStorageBucket(nodeUri, signer, bucketId, label)
    BaseProvider->>BaseProvider: getImpl(nodeUri)
    alt HTTP node
        BaseProvider->>HttpProvider: updatePersistentStorageBucket(...)
        HttpProvider->>HttpProvider: getSignedCommandParams() → authPayload
        HttpProvider->>Node: "PATCH /persistentStorage/buckets/{bucketId}?{authPayload} body: { label }"
        Node-->>HttpProvider: "{ bucketId, label }"
        HttpProvider-->>BaseProvider: PersistentStorageUpdateBucketResponse
    else P2P node
        BaseProvider->>P2pProvider: updatePersistentStorageBucket(...)
        P2pProvider->>P2pProvider: getSignedCommandParams() → authPayload
        P2pProvider->>Node: "P2P: PERSISTENT_STORAGE_UPDATE_BUCKET payload: { ...authPayload, bucketId, label }"
        Node-->>P2pProvider: "{ bucketId, label }"
        P2pProvider-->>BaseProvider: PersistentStorageUpdateBucketResponse
    end
    BaseProvider-->>Client: PersistentStorageUpdateBucketResponse

Loading

_{Reviews (2): Last reviewed commit: "add new codeowner" | Re-trigger Greptile}

[dnsi0]

/run-security-scan

[alexcos20]

AI automated code review (Gemini 3).

Overall risk: low

Summary:
This PR successfully introduces support for setting and updating labels on persistent storage buckets, including updates to types, HTTP, and P2P providers. The code is well-structured and includes integration tests to verify the new functionality. However, there is an inconsistency in how authentication payloads are handled in the HTTP provider's update method compared to creation, which should be addressed to prevent potential API rejection and to keep sensitive signatures out of URL logs.

Comments:
• [WARNING][bug] In updatePersistentStorageBucket, authPayload is being appended to the URL query string. In createPersistentStorageBucket, it is spread into the request body. If the backend API expects the authentication parameters (such as signature and nonce) in the request body for PATCH endpoints, this will result in an authorization error. Additionally, putting signatures in URL parameters exposes them to server access logs.

Consider moving the authPayload into the request body for consistency and better security hygiene:

-    const query = new URLSearchParams({
-      ...authPayload
-    })
-    const response = await fetch(`${routeBase}?${query.toString()}`, {
+    const response = await fetch(routeBase, {
       method: 'PATCH',
       headers,
-      body: JSON.stringify({ label }),
+      body: JSON.stringify({ ...authPayload, label }),
       signal
     })

• [INFO][style] Good cleanup removing the redundant getPersistentStorageSignaturePayload wrapper and calling getSignedCommandParams directly. This reduces boilerplate.
• [INFO][style] Excellent inclusion of an integration test that verifies both the creation of the bucket with a label and the update/renaming flow. LGTM!

[giurgiur99]

AI automated code review (Gemini 3).

Overall risk: low

Summary: This PR successfully introduces support for setting and updating labels on persistent storage buckets, including updates to types, HTTP, and P2P providers. The code is well-structured and includes integration tests to verify the new functionality. However, there is an inconsistency in how authentication payloads are handled in the HTTP provider's update method compared to creation, which should be addressed to prevent potential API rejection and to keep sensitive signatures out of URL logs.

Comments: • [WARNING][bug] In updatePersistentStorageBucket, authPayload is being appended to the URL query string. In createPersistentStorageBucket, it is spread into the request body. If the backend API expects the authentication parameters (such as signature and nonce) in the request body for PATCH endpoints, this will result in an authorization error. Additionally, putting signatures in URL parameters exposes them to server access logs.

Consider moving the authPayload into the request body for consistency and better security hygiene:

-    const query = new URLSearchParams({
-      ...authPayload
-    })
-    const response = await fetch(`${routeBase}?${query.toString()}`, {
+    const response = await fetch(routeBase, {
       method: 'PATCH',
       headers,
-      body: JSON.stringify({ label }),
+      body: JSON.stringify({ ...authPayload, label }),
       signal
     })

• [INFO][style] Good cleanup removing the redundant getPersistentStorageSignaturePayload wrapper and calling getSignedCommandParams directly. This reduces boilerplate. • [INFO][style] Excellent inclusion of an integration test that verifies both the creation of the bucket with a label and the update/renaming flow. LGTM!

Not a bug, the node's PATCH route reads auth from req.query, only label comes from the body, so this matches the backend