[asaah262]

Description

Allow clients to specify a drive ID when creating a project space via POST /graph/v1.0/drives.

• Forward the client-supplied ID to Reva using the existing spaceid opaque field.
• Validate IDs as canonical UUIDs and return 400 Bad Request for invalid values.
• Return 409 Conflict when the storage provider reports that a space already exists.
• Return 409 Conflict when the supplied ID belongs to an existing user.
• Preserve existing behavior when the ID is absent or empty.

Motivation and Context

Currently, Graph ignores client-supplied drive IDs and always lets the storage provider generate a new ID.

This change allows clients to choose the ID when creating a space, while validating the input to prevent invalid space identifiers from reaching the storage layer.

How Has This Been Tested?

Test environment: macOS, Go, local development worktree.

• Added unit tests for ID forwarding, UUID validation, absent/empty IDs, conflict handling, and IDs that belong to existing users (including identity backend errors).
• Added an acceptance scenario covering space creation with a specified UUID, retrieval by drive ID, and duplicate-ID handling.
• All 485 Graph specs passed.
• Graph service tests and relevant race tests passed.
• gofmt and git diff --check passed.
• Acceptance scenario not executed locally (PHP/Behat unavailable); pending CI verification.

Screenshots (if appropriate):

Not applicable.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests only (no source changes)

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation added

AI assistance: Claude Code (claude-opus-5-5) wrote the first draft of the code and the tests.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 15 complexity

Metric	Results
Complexity	15

View in Codacy

🟢 Coverage 100.00% diff coverage · +0.02% coverage variation

Metric	Results
Coverage variation	✅ +0.02% coverage variation (-1.00%)
Diff coverage	✅ 100.00% diff coverage

View coverage diff in Codacy

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (83615f2)	Report Missing	Report Missing	Report Missing
Head commit (768cd26)	92663 (+23)	25441 (+23)	27.46% (+0.02%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#3899)	23	23	100.00%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

¹ Codacy didn't receive coverage data for the commit, or there was an error processing the received data. Check your integration for errors and validate that your coverage setup is correct.

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[pbleser-oc]

looks good, but please have a look at that scenario I added comments for, in case a chosen UUID that is passed as an input parameter corresponds to an existing user UUID that would prevent the personal space from being created for that user (because they exist, but haven't logged in yet)