fix: use NodeID instead of SpaceID for UploadReady event resource_id

[paul43210]

Summary

The UploadReady event and upload-finished callback both set FileRef.ResourceId.OpaqueId to session.SpaceID() instead of session.NodeID(), and include an unnecessary Path field. Every upload reports the space root UUID as the file identifier rather than the actual file's node ID.

Problem

Two locations in decomposedfs construct a Reference with the wrong OpaqueId:

decomposedfs.go:393 (UploadReady event):

OpaqueId: session.SpaceID(),  // BUG: should be session.NodeID()
Path: utils.MakeRelativePath(...)  // REDUNDANT: not needed with correct OpaqueId

upload.go:104 (upload-finished callback):

OpaqueId: session.SpaceID(),  // BUG: should be session.NodeID()
Path: utils.MakeRelativePath(...)  // REDUNDANT: not needed with correct OpaqueId

The correct pattern is already used in the FinishUpload() return value (upload.go:117):

OpaqueId: session.NodeID(),  // CORRECT — no Path needed

Why remove Path?

With OpaqueId pointing directly to the file node, the Path field is redundant. Worse, leaving it causes CODE_NOT_FOUND errors: NodeFromResource() resolves the node from OpaqueId, then tries to walk the Path from that node. Since a file node cannot have children, walking ./dir/filename.ext from a file node fails.

Evidence

From a NATS consumer monitoring UploadReady events, every upload has opaque_id == space_id:

resource_id.opaque_id = "adbf7f74-899e-4ff4-a8f5-56cf4a82f892"
resource_id.space_id  = "adbf7f74-899e-4ff4-a8f5-56cf4a82f892"

16 consecutive uploads confirmed — all affected regardless of file type or size.

Impact

Currently low — all existing oCIS consumers (search, postprocessing, activitylog, clientlog) either ignore the OpaqueId, extract only the SpaceId, or resolve the file via the Path field. However, any consumer that trusts ResourceId.OpaqueId to identify the uploaded file gets the space root instead.

Changes

File	Change
vendor/.../decomposedfs/decomposedfs.go	SpaceID() → NodeID(), removed Path in UploadReady event
vendor/.../decomposedfs/upload.go	SpaceID() → NodeID(), removed Path in upload-finished callback
changelog/unreleased/fix-uploadready-resource-id.md	Changelog entry

Test plan

• Upload a file and verify no CODE_NOT_FOUND errors in logs
• Verify search indexing works correctly after upload
• Verify activitylog and clientlog process uploads without errors

Upstream reva PR: owncloud/reva#546
Fixes: #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

[paul43210]

Closing this PR — after further investigation, the original OpaqueId = SpaceID() + Path pattern is correct CS3 semantics.

In a CS3 Reference, when Path is set, OpaqueId is the anchor node from which the path is resolved. Setting it to SpaceID() (the space root) and providing the relative path is how NodeFromResource() resolves the file: it looks up the space root via OpaqueId, then walks the Path to find the file.

What looked like a bug (OpaqueId == SpaceID) was actually intentional — it means "resolve this path starting from the space root." All consumers (activitylog, clientlog, search) call utils.GetResource(ref) which goes through this resolution path.

Setting OpaqueId = NodeID() without Path broke gateway resolution for consumers that Stat the reference. Setting NodeID() WITH Path caused CODE_NOT_FOUND because NodeFromResource tried to walk the path from the file node (files can't have children).

The FileRef.Path field is also needed by external consumers (face detection service) that read the path directly from the event.