to get a personalized navigation.
to get a personalized navigation.
Hello,
I'm not able to update the associate due to the following error:
{
"errors": [
{
"message": "The request could not be executed: unable to parse response data.",
"path": [
"useCompany",
"associate_update"
]
}
],
"data": {
"useCompany": {
"associate_update": null
}
},
"extensions": {
"vbnxt-trace-id": "0000000000000000b61cd6ca13a0f194"
}
}
The request:
mutation UpdateAssociate($companyId: Int) {
useCompany(no: $companyId) {
associate_update(filters : [{ supplierNo : {_eq : 9420911}}], values: [
{
addressLine1: "*",
addressLine2: "*",
postCode: "*",
postalArea: "*",
bankAccount: "*",
name: "*"
}
]) {
affectedRows
items { associateNo
name
customerNo
supplierNo
externalId
invoiceCustomerNo
factoringCompanyNo
title
companyNo
emailAddress
phone
privatePhone
mobilePhone
addressLine1
addressLine2
addressLine3
addressLine4
postCode
postalArea
visitPostCode
visitPostalArea
countryNo
deliveryMethodForCustomer
deliveryTermsForCustomer
paymentTermsForCustomer
paymentMethodForCustomer
currencyNo
generalLedgerAccountNoForCustomer
yourReference
customerPreferences1
}
}
}
}
Do you have na idea what is the root cause?
This problem has been fixed and will be deployed to prod on Monday. You will now get an error message as follows:
"errors": [
{
"message": "Error: Reserved by process 12345, started 2024.12.6, 6:25 PM by john.doe.",
"path": [
"useCompany",
"associate_update",
"values/0"
],
"extensions": {
"data": {
"status": 22,
"status_name": "lockedByAnotherProcess"
},
"details": "GraphQL.ExecutionError: Error: Reserved by process 12345, started 2024.12.6, 6:25 PM by john.doe."
}
}
A possible scenario for this to occur is the following:
- in the front end, somebody edits a record (such as a customer)
- the save button is not pressed, and therefore the record is locked for changes by other processes (such as another front-end instance or API)
- a GraphQL mutation is executed to update the locked record
To fix it, if the front-end session is still open, save or discard changes. If the session was closed without doing so, then the locks need to be removed manually.
Great improvment,
but could you please be a bit more careful with such breaking changes? We have a retry strategy in our code exactly due to this problem:
(result.StatusCode == HttpStatusCode.OK && (content?.Contains("The request could not be executed: unable to parse response data") ?? false) && attempts < 4)
This change breaks absolutely all integrations for all customers here where the row is locked!
Florian
We have implemented this now and are checking the statuscode instead.
@iizy The root cause is that the row you are trying to update is locked by another process.
We will improve the error reporting in such cases so you receive information about the root cause instead of "unable to parse response data".
@Arnstein By Sounds good, but what we should do when the associate that we want to update is locked by another process?
I guess you have to retry the operation after the lock is released.
@Arnstein By We were trying to do it couple of times but still we receive the same errror message.
Is there any other way / solution?
It's not a good practice, but you can cancel an active lock.
mutation CancelLock($customerNo: Int!, $activeProcessNo: Int!) {
useCustomer(no: $customerNo) {
activeSystemProcess_processings {
cancelLocking(filter: {activeProcessNo: {_eq: $activeProcessNo}}) {
succeeded
}
}
}
}
@iizy Not to my knowledge, the update will fail as long as the record is locked. Please contact Customer Success for advice on how to remove locks manually if you are not familiar with this procedure.
Hi @iizy, we are looking into this.
Copyright © 2022 Visma.com. All rights reserved.