In rest we use this function to delete removed line items from an order:
_deleteRemovedItems(order) {
try {
const lineItems = order.line_items;
const refundedItems = order.refunds
.filter((refund) => refund.transactions.length === 0)
.map((refund) => refund.refund_line_items || )
.flat()
.reduce((obj, value) => {
const oldQty = obj[value.line_item_id];
obj[value.line_item_id] = oldQty
? oldQty + value.quantity
: value.quantity;
return obj;
}, {});
const newLineItems = [];
lineItems.forEach((item) => {
if (refundedItems[item.id] !== undefined) {
if (item.quantity - refundedItems[item.id] > 0) {
newLineItems.push({
...item,
quantity: item.quantity - refundedItems[item.id],
});
}
} else {
newLineItems.push(item);
}
});
return newLineItems;
} catch (error) {
console.log(
`error in : _deleteRemovedItems while processsing order id: ${order?.id}`,
error,
);
}
}
But now we’re migrating to graphql and also using bulk query to fetch the order data, but the problem is that refundLineItems are buried beyond the limit specified for bulk query nesting levels. Now the problem is that we generate reports based on this data, Querying this refundLineItems for each order via graphql is time taking and not feasible for us as it consumes all the available graphql cost and makes the app unusable on larger stores.
Please add refunds on the queryRoot for bulk queries and also add some kind marker to know which line item is removed from the order.
3 Likes
May I ask why you are removing line items from the order?
I can submit a feature request for this, @tapan_kashyap.
First though, could you share a little more about the business logic for this query? The reason I ask is I’d like to explore if there are any alternative endpoints that may work instead.
Sure, Some of merchants remove line items from the order e.g. if customer wants a different variant from what they ordered initially, then merchant will remove the original lineitem & add the new one and we don’t want to show those line items in the invoices & reports.
Yeah sure, We process order & refunds data to generate reports, for that we need order data along with refunded line items. basically we loop over this data to generate sales & credit note reports.
Currently As a workaround we are fetching order data via bulk query but since we can’t get the refunded line items then we do normal graphql query to fetch the refunds data for all the orders which have been refunded.
If get the refunded line items data in the bulk query then we’ll be able to process this much more easily & without gql api exhausting the rate limits.
Thanks for that context.
For a possible workaround, have you tested using the sales agreement connection? I know this field doesn’t implement node, however it will work with bulk operations up until orders that have over 250 agreements. Since that would be rare on most orders you could use your current process as a fallback when this happens.
Adding node to these connections is something on our teams radar, so I’ll be sure to pass on the feedback from this thread as well.
Thanks for suggestion, I tried that actually, but this doesn’t gives us what we needed like the order data along with line items, refunds & refunds line items etc. For now our current process works kinda ok.
1 Like