Hi @Theodor_Freund_at_HT , thanks for reaching out!
Just want to confirm I get it right:
You’re firing a GraphQL request to load the fulfillment orders assigned to your Fulfillment Service App. So you’re using your app’s access token and sending a request with a payload similar to the following:
query getAssignedFulfillmentOrders {
assignedFulfillmentOrders(first: 10, assignmentStatus: CANCELLATION_REQUESTED) { ... }
}
But if you call it right after a “cancellation request” callback request, it might not contain the fulfillment order you’re looking for. Is that correct?
After investigating the code I can confirm that this behaviour can occur when the callback request is sent very quickly. Given the way we manage the state, aiming for upmost consistency in our data, we first send the webhook events and, only if they succeed, we start the process of updating the fulfillment order status in the database. This means that we can have a small delay between the time you receive the callback event and when the status is updated.
Consider one of the following approaches to address it:
- If possible, add a small delay in your app from the time you receive the webhook to when you call the
assignedFulfillmentOrdersGraphQL query. This is likely a background job in your system that shouldn’t affect the user experience; - Use webhooks, which are a more robust alternative to fulfillment service callbacks. The webhooks are fired after all the data has been updated and you can also get extra data from it, possibly removing the need for an extra request to
assignedFulfillmentOrdersin your flow. You could create a webhook subscription for the cancellation request event with the following payload:
mutation subscribeToWebhook {
webhookSubscriptionCreate(
topic: FULFILLMENT_ORDERS_CANCELLATION_REQUEST_SUBMITTED,
webhookSubscription: {
callbackUrl: "<WEBHOOK_CALLBACK_URL_GOES_HERE>",
format: JSON,
}
) {
userErrors {
field
message
}
webhookSubscription {
id
}
}
}