Idempotency is based on an int computed from submit.input().hashCode() xor submit.agent().wire().hashCode() in arcp-runtime/src/main/java/dev/arcp/runtime/session/SessionLoop.java around line 379, and IdempotencyStore only persists that int at arcp-runtime/src/main/java/dev/arcp/runtime/idempotency/IdempotencyStore.java around line 43. This can treat different submissions as identical because 32-bit hash collisions are possible, and it ignores lease_request, lease_constraints, max_runtime_sec, and any other fields that affect execution. Reusing an idempotency key with changed execution parameters can therefore return the original job instead of raising DUPLICATE_KEY.
Fix prompt: Replace the int payload hash with an exact idempotency fingerprint over all semantically relevant JobSubmit fields. Use the shared ObjectMapper to serialize a canonical JSON representation, include agent, input, lease_request, lease_constraints, idempotency_key scope, and max_runtime_sec as appropriate, and store either the canonical bytes or a collision-resistant digest such as SHA-256. Compare the full fingerprint in matchesPayload. Add tests proving changed input, agent, lease, constraints, and max_runtime_sec conflict under the same key, plus a regression test that two distinct payloads with colliding Java hashCode values do not reuse a job.
Idempotency is based on an int computed from submit.input().hashCode() xor submit.agent().wire().hashCode() in arcp-runtime/src/main/java/dev/arcp/runtime/session/SessionLoop.java around line 379, and IdempotencyStore only persists that int at arcp-runtime/src/main/java/dev/arcp/runtime/idempotency/IdempotencyStore.java around line 43. This can treat different submissions as identical because 32-bit hash collisions are possible, and it ignores lease_request, lease_constraints, max_runtime_sec, and any other fields that affect execution. Reusing an idempotency key with changed execution parameters can therefore return the original job instead of raising DUPLICATE_KEY.
Fix prompt: Replace the int payload hash with an exact idempotency fingerprint over all semantically relevant JobSubmit fields. Use the shared ObjectMapper to serialize a canonical JSON representation, include agent, input, lease_request, lease_constraints, idempotency_key scope, and max_runtime_sec as appropriate, and store either the canonical bytes or a collision-resistant digest such as SHA-256. Compare the full fingerprint in matchesPayload. Add tests proving changed input, agent, lease, constraints, and max_runtime_sec conflict under the same key, plus a regression test that two distinct payloads with colliding Java hashCode values do not reuse a job.