POST /norm-expansion/norms/ returns 500 and rolls back (MissingGreenlet in NormResponse serialization)

[mherrerap87]

Version: 16.0.0 (Docker, linux/amd64) · Endpoint: POST /api/v1/norm-expansion/norms/

Creating a norm via the API fails with HTTP 500 and — more importantly — the transaction
is rolled back, so the norm is not persisted even though it was created in the session.

Backend log:

pydantic_core._pydantic_core.ValidationError: 1 validation error for NormResponse
  Error extracting attribute: MissingGreenlet: greenlet_spawn has not been called;
  can't call await_only() here. Was IO attempted in an unexpected place?
  input_value=<ProductionNorm sc-mo-038 (m2)>

This looks like the same class of bug fixed for budgets in v16.0.0 (response
serialization triggering a lazy load under async SQLAlchemy → session.refresh()
before serializing). Reproduced with a minimal body:

{"work_key": "sc-mo-038", "name": "Test norm", "unit": "m2",
 "category": "Test", "labor_hours_per_unit": 1.5, "notes": "test", "is_active": true}

Result: 500 + SELECT count(*) FROM oe_norm_expansion_norm WHERE work_key='sc-mo-038' → 0.

Note: machine_hours_per_unit also has a NOT NULL constraint in the DB while the API
schema marks it nullable — sending null fails with an IntegrityError; 0 works.
Workaround we used: direct SQL insert. Happy to test a fix.

[datadrivenconstruction]

Thanks for this, @mherrerap87. Both halves are fixed.

The 500 was create_norm appending into norm.materials from inside the loop over
the request body, so a body carrying no materials never touched the collection
at all. An untouched collection on a row the flush has just made persistent is
unloaded rather than empty, and the router reads it from a synchronous
NormResponse.model_validate, where the selectin loader tries to emit its SELECT
outside the async greenlet. That is the MissingGreenlet you saw, and the
rollback behind it is why your count came back zero. The collection is assigned
rather than appended into now, which marks it loaded even when it is empty, and
the norm is still transient at that point so the assignment never touches the
database. It is in backend/app/modules/norm_expansion/service.py.

You were right about machine_hours_per_unit too, and the disagreement was wider
than that one field. Every field on NormUpdate is typed optional to mark "not
supplied", and model_dump with exclude_unset cannot tell an omitted field from
one sent as null, so an explicit null reached the column and failed the flush.
The database is the side that is right here, because a null productivity
coefficient has nothing to mean when the expansion math multiplies it, so the
schema refuses an explicit null across the whole model now and answers 422.
work_key was the worst of them, since a minimum length does not apply to None.
Omit a field to leave it unchanged. The numeric fields take 0 and name,
category and notes take an empty string if you want to clear them; work_key and
unit are required and will not accept a blank.

Your minimal body is the first of the regression tests, in
backend/tests/unit/test_norm_expansion_create_api.py, and they assert the row is
in the database rather than that the response looked right, because the status
code was never the part that mattered.

Both halves are in 16.2.0, so an upgrade from the 16.0.0 image you are on will
pick them up.

DataDrivenConstruction