Gotcha. Thanks, we'll handle it in application code then.
- Logan
On Mon, Oct 23, 2023 at 9:41 AM Dave Marion wrote:
> By design, we typically don't send user data back in error messages so
> that we are not leaking data into a client side log or something.
>
> On Mon, Oct 23, 2023 at 8:43 AM
By design, we typically don't send user data back in error messages so
that we are not leaking data into a client side log or something.
On Mon, Oct 23, 2023 at 8:43 AM Logan Jones wrote:
> Hi Ed / Josef:
>
> Yes, the violation summaries are available, but I was hoping that the
> actual mutati
Hi Ed / Josef:
Yes, the violation summaries are available, but I was hoping that the
actual mutations objects would be available somewhere on the exception.
After looking at this more, I'm fairly certain that the mutations that
caused the violation are not really available which is unfortunate for
If you catch the MutationRejectedException you can get the violations.
Something like:
} catch (MutationsRejectedException mex) {
log.warn("Failed to update reference for table: " + tableName);
log.warn("Constraint violations: {}", mex.getConstraintViolationSummaries());
throw new Ille
Hi Logan,
If there was a constraint violation portion of the exception (the exception was
not truncated), did that not provide enough info?
Could you post the exception? That always helps 🙂
Josef Roehrl
FuseForward | Senior Architect - Professional Services
[https://fuseforward.atlassian.net/w
