https://sonarly.com/issue/4115?type=bug
The UpdateWorkflowVersionStep mutation returns a step object with an invalid `position` field (non-null object with null/undefined `x` and `y`), causing GraphQL to throw a non-nullable field violation on `WorkflowStepPosition.x`.
Fix: Added a `sanitizeStepPosition` private method and position normalization logic to `WorkflowVersionStepUpdateWorkspaceService.updateWorkflowVersionStep()`.
**What changed:**
1. **Position fallback** (line 76-78): After obtaining `updatedStep` from either the type-changed or settings-only path, the code now resolves position using `updatedStep.position ?? existingStep.position`. This means if the client input doesn't include position (common for settings-only updates), the existing position from the database is preserved rather than lost.
2. **Position sanitization** (lines 108-120): A new `sanitizeStepPosition` method validates that if position is defined, both `x` and `y` must be actual numbers (`typeof === 'number'`). If either is missing, null, undefined, or non-numeric, the entire position is set to `undefined` — which GraphQL correctly resolves as `null` for the nullable `position` field on `WorkflowActionDTO`. This prevents the `Cannot return null for non-nullable field WorkflowStepPosition.x` error.
3. **Normalized step used everywhere** (lines 80-105): The `normalizedUpdatedStep` (with sanitized position) is used both for saving to the database and as the GraphQL return value, ensuring consistency between what's persisted and what's returned.
The fix is applied at the single return point of the public `updateWorkflowVersionStep` method, covering both the type-changed path (where `existingStep.position` from DB could be corrupted) and the settings-only path (where client input typically omits position).
Sonarly Claude Code
d2746d2778