Bugfix: Why did generated platform CRUD inserts return HTTP 201 but ...

Documentation for Sessions

🐛 Bugfix: Why did generated platform CRUD inserts return HTTP 201 but ...

Date: 2026-03-23
Time: 22:37:33 UTC
Session: gspace1-261.12
Agent: angular
Confidence: 98%
Status: ✅ Documented

📋 Decision Context

Question:

Why did generated platform CRUD inserts return HTTP 201 but silently fail to persist data?

Task: S257: Platform CRUD persistence

🎯 Decision Made

Chosen:

Fixed entity-schema.service.ts validateData() to use field.name instead of field.key, and skip auto-generated fields (id, createdAt, updatedAt). The generation pipeline registers schemas with field.name but the validator read field.key (undefined), producing errors like 'undefined is required' for every required field.

Options Considered:

  1. Fix only the field.key→field.name mapping
  2. Remove schema validation entirely
  3. Fix the generation pipeline to use field.key instead of field.name

💭 Reasoning

Root cause: The generation pipeline's BACKEND_SETUP phase registers entity schemas via POST /data/schemas. These schemas use {name: 'fieldName', type: 'string', required: true}. But validateData() at entity-schema.service.ts:93 accessed field.key (which doesn't exist) instead of field.name. This produced 'undefined is required' for ALL required fields. The HTTP response was 201 (NestJS default for POST) but the body contained {success: false, errors: [...]}. The preview stub's fetch silently caught this error and returned empty data. Three independent bugs compounded: (1) field.key vs field.name naming mismatch, (2) auto-fields like id/createdAt marked required but backend-generated, (3) silent error swallowing in fetch catch. Fix addresses all three.

📁 Files Involved

🔗 Related

Auto-generated by MCP Smart Consolidation