Defect classes (two sub-issues bundled)
C1: unassign* operations fail with 204→404 — read/write sequencing gap
8 specs fail with expected 204, got 404 on the main unassign* step:
unassignClientFromGroupunassignMappingRuleFromGroupunassignRoleFromClientunassignRoleFromGroupunassignRoleFromMappingRuleunassignRoleFromUserunassignUserFromGroup- (and
modifyProcessInstance)
All seven unassign* chains follow the same pattern: create<Resource> → assign<Resource>To<Container> → unassign<Resource>From<Container>. The intermediate assign* step returns 2xx (no failure recorded), but the immediately following unassign* returns 404.
Hypothesis: eventual consistency. The assign* write completes synchronously on the gateway but the export to the secondary store (which unassign* reads from to validate the relationship exists before deleting) hasn't caught up. The generator currently emits no readback / no polling between sibling write steps.
Class-scoped fix: between any assign* and a sibling unassign* (or any write-then-delete chain), emit either:
- a read-back polling helper (Awaitility-style) until the just-written relationship is visible, or
- a small fixed delay (last resort, brittle).
The repo already has a similar awareness gap tracked in #310 ("Awareness: readback after mutation with no semantic types"). This may collapse into that issue — please cross-reference and dedupe if appropriate.
C2: searchResources fails with 200→405 — upstream verb mismatch
2 specs fail (searchResources base + negative variant):
POST /v2/resources/search
→ HTTP 405 {"title":"Method Not Allowed","detail":"Method 'POST' is not supported."}
The bundled spec declares POST /resources/search:
$ node -e "const s=require('./spec/camunda-oca/bundled/rest-api.bundle.json'); console.log(Object.keys(s.paths['/resources/search']))"
[ 'post' ]
But the running camunda server rejects POST. Two possibilities:
- Spec is wrong (should be GET). → file upstream at
camunda/camunda.
- Server is wrong (should support POST). → file upstream at
camunda/camunda.
Either way, this is not a generator defect: the generator faithfully emits what the spec declares.
Action for this repo: none, beyond confirming via curl (done — 405 confirmed). File a corresponding upstream issue and reference it back here.
Out-of-scope (separate upstream tickets to file)
The triage surfaced three more singletons that are also upstream, not generator-side. Listing here for visibility; do not address in this issue:
createAdminUser → 403 (bootstrap permission — cluster config).getAuthentication → 401 (auth scheme mismatch — cluster config).resolveProcessInstanceIncidents → 415 (PATCH with empty body missing Content-Type: application/json — possibly generator-side emit Content-Type even when body is empty policy gap).correlateMessage, createAgentInstance / getAgentInstance / searchAgentInstances / updateAgentInstance → 404 (endpoints likely not deployed in OCA cluster profile).
Acceptance criteria
- C1 sub-issue:
- Red L3 invariant fails on
main: "no unassign* step is emitted without a preceding readback/polling guard for its assign* sibling".
- Generator change in
materializer/ (likely the chain-emission path) makes it pass.
- The 7
unassign* 404 failures all turn green when run against the live cluster.
- C2 sub-issue: closed when the upstream camunda/camunda issue is opened and linked.
Discovered during triage of #325 follow-up. See PR #325 for context.
Defect classes (two sub-issues bundled)
C1:
unassign*operations fail with 204→404 — read/write sequencing gap8 specs fail with
expected 204, got 404on the mainunassign*step:unassignClientFromGroupunassignMappingRuleFromGroupunassignRoleFromClientunassignRoleFromGroupunassignRoleFromMappingRuleunassignRoleFromUserunassignUserFromGroupmodifyProcessInstance)All seven
unassign*chains follow the same pattern:create<Resource>→assign<Resource>To<Container>→unassign<Resource>From<Container>. The intermediateassign*step returns 2xx (no failure recorded), but the immediately followingunassign*returns 404.Hypothesis: eventual consistency. The
assign*write completes synchronously on the gateway but the export to the secondary store (whichunassign*reads from to validate the relationship exists before deleting) hasn't caught up. The generator currently emits no readback / no polling between sibling write steps.Class-scoped fix: between any
assign*and a siblingunassign*(or any write-then-delete chain), emit either:The repo already has a similar awareness gap tracked in #310 ("Awareness: readback after mutation with no semantic types"). This may collapse into that issue — please cross-reference and dedupe if appropriate.
C2:
searchResourcesfails with 200→405 — upstream verb mismatch2 specs fail (
searchResourcesbase + negative variant):The bundled spec declares
POST /resources/search:But the running camunda server rejects POST. Two possibilities:
camunda/camunda.camunda/camunda.Either way, this is not a generator defect: the generator faithfully emits what the spec declares.
Action for this repo: none, beyond confirming via curl (done — 405 confirmed). File a corresponding upstream issue and reference it back here.
Out-of-scope (separate upstream tickets to file)
The triage surfaced three more singletons that are also upstream, not generator-side. Listing here for visibility; do not address in this issue:
createAdminUser→ 403 (bootstrap permission — cluster config).getAuthentication→ 401 (auth scheme mismatch — cluster config).resolveProcessInstanceIncidents→ 415 (PATCH with empty body missingContent-Type: application/json— possibly generator-sideemit Content-Type even when body is emptypolicy gap).correlateMessage,createAgentInstance/getAgentInstance/searchAgentInstances/updateAgentInstance→ 404 (endpoints likely not deployed in OCA cluster profile).Acceptance criteria
main: "nounassign*step is emitted without a preceding readback/polling guard for itsassign*sibling".materializer/(likely the chain-emission path) makes it pass.unassign* 404failures all turn green when run against the live cluster.Discovered during triage of #325 follow-up. See PR #325 for context.