[docs-only] fix: add ResourceID field to UploadReady event with file's node ID

[paul43210]

Summary

The UploadReady event's FileRef.ResourceId.OpaqueId is set to the space root ID (required for CS3 gateway path resolution). NATS consumers that need the file's actual node ID for Graph API URLs or metadata writes get the space root instead.

Problem

FileRef uses OpaqueId = session.SpaceID() because NodeFromResource() uses OpaqueId as the anchor for WalkPath(Path). This is correct for CS3 gateway resolution, but means FileRef.ResourceId cannot be used as a file identifier.

A previous fix attempt (PR #12057, closed) changed OpaqueId to session.NodeID(), which broke:

• CS3 gateway resolution (WalkPath from a file node fails with CODE_NOT_FOUND)
• Removing Path to work around that broke external consumers that need the file path

Fix

Add a separate ResourceID field to the UploadReady event, following the same pattern already used by BytesReceived:

ResourceID: &provider.ResourceId{
    StorageId: session.ProviderID(),
    SpaceId:   session.SpaceID(),
    OpaqueId:  session.NodeID(),  // actual file node ID
},

FileRef is unchanged — CS3 gateway resolution and Path continue to work. JSON deserialization silently ignores unknown fields, so existing consumers are unaffected.

Changes

File	Change
vendor/.../events/postprocessing.go	Add ResourceID *provider.ResourceId to UploadReady struct
vendor/.../decomposedfs/decomposedfs.go	Populate ResourceID with session.NodeID()
vendor/.../posix/tree/assimilation.go	Populate ResourceID from existing ref.ResourceId
changelog/unreleased/fix-uploadready-resource-id.md	Changelog entry

Test plan

• Upload a file and verify UploadReady NATS event contains both FileRef (with Path) and ResourceID (with correct OpaqueId)
• Verify activitylog, clientlog, search continue to work (they use FileRef)
• Verify external consumer can read ResourceID.OpaqueId as the file's node ID

Upstream reva PR: owncloud/reva#547
Related: #12056

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[2403905]

@paul43210 Thank you for your PR.
I read this one and the related tickets. I can't figure out which exact bug this PR should fix.
Could you point me to the consumer that is missing the resource ID?
What I see from the code is that the consummers useFileRef.
activitylog
clientlog
search

[paul43210]

Thanks for the review @2403905!

You're right that the built-in oCIS consumers (activitylog, clientlog, search) all use FileRef and work fine — they resolve the file via FileRef.Path relative to the space root.

The consumer that needs the actual file node ID is an external NATS event consumer — a face detection service that subscribes to UploadReady events to process uploaded photos. It needs the file's OpaqueId (node ID) to construct Graph API URLs like:

/graph/v1.0/drives/{space_id}/items/{opaque_id}

Currently FileRef.ResourceId.OpaqueId is the space root ID (identical to SpaceId), so those URLs resolve to the space root instead of the file. The service can't use the CS3 gateway — it only has WebDAV/Graph API access.

The BytesReceived event already has this same pattern — a separate ResourceID field with the actual file node ID alongside the gateway-resolvable reference. This PR applies the same approach to UploadReady.

That said, if an external consumer use case isn't compelling enough for this change, I understand. Happy to discuss alternative approaches.

[2403905]

Hi @paul43210. Sorry for the delay.
The OCIS doesn't share the ResourceID because the clients can do the extra webDav PROPFIND call using the relative path to get the file id and other info. The changes are looks reasonable to avoid the extra call for each file in case the client wants uses id.

[2403905]

The reva changes should go first

[2403905]

Related PR owncloud/reva#547

[2403905]

@paul43210 I merged the reva #12087 to ocis. It includes the related pr #547
What you need to do to have this pr merged:

• remove the vendor directory and keep only changelog/unreleased/fix-uploadready-resource-id.md
• Add the link https://github.com/owncloud/reva/pull/547 to the changelog/unreleased/fix-uploadready-resource-id.md tail
• rebase git pull --rebase origin master and push
  Thaks.

[paul43210]

@2403905 Thanks for the guidance! I've rebased onto master, squashed into a single commit, and added the reva PR #547 link to the changelog.

Re: removing the vendor directory — I checked and the reva bump in PR #12087 only added the new ResourceID field. The FileRef fixes (changing OpaqueId from SpaceID() → NodeID() and removing Path) are still not in the vendored reva on master. So I've kept those two vendor changes as they're needed for the FileRef fix described in the original issue.

The PR now contains just:

• changelog/unreleased/fix-uploadready-resource-id.md (with reva Searching sharee with displayname #547 link added)
• vendor/.../decomposedfs.go — FileRef OpaqueId fix
• vendor/.../upload.go — FileRef OpaqueId + Path removal

[2403905]

Hello @paul43210 I see the upload.go changes in a closed pr owncloud/reva#546
If you want to add it to the reva, please make a new pr. Then I'll bump the reva in an ocis

[paul43210]

@2403905 Done — opened reva PR #560 with the FileRef fix and it's been merged. Whenever you bump reva in oCIS, I'll rebase this PR. Thanks!