Consumes a session token from soft-save and persists the product-brick edits as a new entity version. Entries in excludedAssertions are stripped from each test case's expectedOutput before persistence.
Test-case lock-in (important). Hard-save deliberately rotates the test-case cohort: every id in keepTestCaseIds is archived against the previous entity version, and a new test-case row is created against the just-persisted version. This locks each kept test case to the entity version it was last validated against — that is the whole point of hard-save, and it is the only way to keep expectedOutput aligned with the entity that produced it.
What this means for callers: the test-case ids you sent in keepTestCaseIds are no longer the current cohort once this call returns 200. Use the freshly minted ids returned in newTestCaseIds for any follow-up POST /products/{productId}/test-cases/run or GET /products/{productId}/test-cases/{testCaseId} call. The archived rows remain queryable by id (their cohortTimestamp is stamped with the new validFrom) but they will not be picked up by the cohort-scoped run/list endpoints.
testCasesCreated counts both the kept-cohort rows (one per keepTestCaseIds entry) and any delta-shifted rows produced by soft-save. testCasesDeleted counts ids the caller passed to soft-save but omitted from keepTestCaseIds.
| Time | Status | User Agent | |
|---|---|---|---|
Retrieving recent requests… | |||
bad request
unauthorized
Concurrent edit detected. Returned with internalCode: "CONFLICT_RETRY" when the new version cannot be persisted because another writer already landed at the requested validFrom (or the soft-save session is otherwise stale relative to the latest persisted version). Re-fetch the latest version, re-soft-save, and retry. The v5 soft-save surfaces auto-bump non-future validFrom values to max(now, latest.validFrom + 1) so this should only fire under genuine cross-session concurrency.