fix(resolutions): refresh the upserted row before serialising it

[smaramwbc]

Closes #367.

The problem

POST /v1/resolutions upserts by (subject_id, session_id, tenant_id). The first write to a logical key returns 200; every write after it returns 500 internal_error and persists anyway.

200
500
500
500     # four writes to one key — and the read-back shows the fourth value

The only upsert-by-logical-key on the consumer surface was telling callers their write had failed, after committing it.

Root cause

create_resolution serialises the row it gets back after the commit:

result = await repo.upsert_resolution(session, row)
await session.commit()

return ResolutionResponse.from_row(result)

session.commit() expires every instance in the session, so reading a column off result is lazy IO. On the async engine that raises MissingGreenlet, which falls into the catch-all handler in server/core/errors.py and reaches the client as a 500.

It only bit the UPDATE path, which is why it survived this long. upsert_resolution returns the instance the request just constructed on INSERT — attributes still populated in Python, no refresh needed. On UPDATE it returns the row it loaded from the database, which the commit expired.

The fix

The pattern POST /v1/episodes already uses for the same reason: commit, then await session.refresh(result). One line plus the comment explaining which path it protects and why.

I audited the other routers rather than assuming this was the only instance. subjects.py reads only plain ints after its commit; health.py I checked empirically — 200 on repeated calls. resolutions.py was the one route that commits and then reads ORM attributes without refreshing.

What this is not

• Not a regression from [Bug]: Duplicated field-by-field response mapping across API routers (timeline.py, resolutions.py, etc.) #295 / Fix/295 response mapping #356. That refactor is the obvious suspect, and it is innocent: from_row reads exactly the same nine fields the inline mapping read, also after the commit. I checked out b99596b~1 and ran it — 200, 500, 500, identical. The defect dates to d4fef67, where the endpoint was introduced.
• Not covered by fix: return 503 service_unavailable on database outage #366. That maps sqlalchemy.exc.OperationalError to 503. MissingGreenlet is an InvalidRequestError, so it still falls to the catch-all.
• No semantics change. Same rows written, same upsert key, same status vocabulary. Only the transport result changes, from a wrong 500 to the 200 the write had already earned.

Tests

tests/integration/test_resolutions_upsert_update.py, three cases, all three fail on main:

test	asserts
test_repeated_writes_to_one_key_all_succeed	four writes to one key, every one a 200
test_the_update_response_carries_the_new_value	the body describes the write that just happened — a status-code-only assertion would pass against a route returning a stale first-write body
test_the_upsert_still_collapses_to_one_row	one logical key, one row, latest value, and resolved_at cleared when the status moves back off resolved

Verification

• New tests: 3 passed with the fix, 3 failed without it (MissingGreenlet in the captured log).
• tests/integration -k "resolution or sla or golden or claim or timeline or edge": 57 passed.
• ruff check server/ tests/: clean.
• Unit suite: 960 passed. tests/test_config.py::test_compiler_type_default_is_valid and ::test_embedding_provider_default_is_valid fail in a whole-directory run both with and without this change — test-order pollution, they pass when that file runs alone. Unrelated.

Run against Postgres 16 + pgvector with no API key and no LLM key, from source and against the published statewavedev/statewave:1.5.0 image.