Class CurationCommitConflictException

java.lang.Object
java.lang.Throwable
java.lang.Exception
java.lang.RuntimeException
jakarta.ws.rs.WebApplicationException
jakarta.ws.rs.ClientErrorException
ubic.gemma.rest.util.CurationCommitConflictException
All Implemented Interfaces:
Serializable
public class CurationCommitConflictException extends jakarta.ws.rs.ClientErrorException
A curation commit refused as a 409, carrying which conflict it was.

The endpoint has several ways to answer 409 and a client has to do something different for each: re-read and re-diff, ask the curator to consent, or fix the body. Told apart only by the prose in the message, that choice becomes string-matching against sentences nobody promised to keep — so the reason travels as a stable code in errors[0].reason, mapped by CurationCommitConflictExceptionMapper.

🛑 A stale baseline deliberately does not hand back the current token. The client cannot simply retry with a fresher one: its draft was built against a state that no longer holds, so committing over the change it has not seen is exactly the overwrite the token exists to prevent. Re-read, re-diff, then commit.

Extends ClientErrorException so RequestExceptionLogger keeps logging it as the client-side outcome it is — one WARN line, no server-fault stack trace.

Author:
gemma
See Also: