ShopifySharp
ShopifySharp copied to clipboard
Checkout API Line Item Id not Long
Hello,
This library is so awesome. I'm trying to get some checkout items, but it looks like for a certain client, the Id property for the CheckoutLineItem is actually not a long, but what looks to be a token. This does not look normal, but looking for a way to get around this for now and maybe ignore this field when pulling the data via the ListAsync method.
I will try to branch and see if I can make a local fix for now.
Do you have any suggestions?
Thanks, David
What about the Key property? Is it ever different to the Id?
The Key property looks to be the same as the Id, this is what I am seeing:
"line_items": [
{
"applied_discounts": [],
"key": "78e190b6a798d31a2dee11b40e14d8b7",
"compare_at_price": null,
"destination_location_id": 195835888002922,
"fulfillment_service": "manual",
"gift_card": false,
"grams": 397,
"line_price": "29.95",
"origin_location_id": 18918588392682,
"price": "29.95",
"product_id": 59036717762410,
"properties": null,
"quantity": 1,
"requires_shipping": true,
"sku": "",
"tax_lines": [],
"taxable": true,
"title": "N/A",
"variant_id": 794547299999466,
"variant_title": "",
"vendor": "N/A",
"tax_code": null,
"id": "78e190b6a798d31a2dee11b40e14d8b7"
}
I get an exception when calling the ListAsync method. I would suggest to add Id as a string field on CheckoutLineItem, but judging by the inheritance this may mess things up.
One idea that comes to mind would be to change CheckoutLineItem so that it doesn't inherit from LineItem and declares its own properties instead.
Yea I will try that! Also was thinking of hiding the inherited member by using the new keyword and adding it on the CheckoutLineItem class
It's weird because I see most other clients have the Id field and Key as a long.... very strange
Let's run this idea with @nozzlegear first.
Ok, I will test locally in the meantime.
Thanks for the quick help!
Quick Update, looks like adding the new
modifier helps for now(exception is gone) but I am worried about the case where other CheckoutLineItems have an Id field of type long
. Not sure about deserializing. I will try changing the inheritance to see what happens too.
Haven't run into this one before. I wonder if checkout line item ids are strings for every store, or just for your specific store? If it's every store then we could easily update the value type to string, but if it isn't we'd just end up breaking it for everyone that has a long id instead.
@nozzlegear Yea I have been querying a few stores and it looks like that Id has changed to a string. The only weird thing I have noticed is that some stores when I get the checkouts, the Id field is missing entirely from the line items.... They're doing some weird stuff over there.
Very strange. To be honest I'm not sure what to do here! We could change the Id
type to object, which would let it be either a string or a long, but then we'd have to stop inheriting from the base ShopifyObject
which means it would no longer work with the service methods. 🤔
Well I havent had any problems doing this with the code:
using Newtonsoft.Json;
using ShopifySharp.Enums;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace ShopifySharp
{
public class CheckoutLineItem : LineItem
{
/// <summary>
/// The key for the line item.
/// </summary>
[JsonProperty("key")]
public string Key { get; set; }
/// <summary>
/// The unique numeric identifier for the product in the fulfillment. Can be null if the original product associated with the order is deleted at a later date
/// </summary>
[JsonProperty("origin_location_id")]
public long? OriginLocationId { get; set; }
[JsonProperty("id")]
public new string Id { get; set; }
}
}
I was able to get checkouts without any problems for over 600 clients.
I'm glad this was such an easy fix, but I'm hesitant to make the change to the package right now. I'm going to try getting in touch with somebody at Shopify to see if this is intentional. If it's something they might be moving to in the future, then switching the Id
prop of all objects to a string in 5.0 would be a good way to future proof this.
It looks like the checkout line items are indeed a string in Shopify's documentation, so I'll get this property changed over to string. Technically it's a breaking change, but the current implementation itself is broken so I'll push this without waiting for 5.0.
I've been playing a bit with the checkout API.
It's quite confusing, there are actually 2 different APIs: Abandoned checkout: https://help.shopify.com/api/reference/abandoned_checkouts Checkout: https://help.shopify.com/api/reference/checkout
They both live under /admin/checkouts.json
It's not really clear to me how they relate to each other and how the checkouts/* webhooks work.
At this point, only the Abandoned checkout is implemented in ShopifySharp.
What I'm seeing is that the line items actually have no Id
property. Only a key.
I was able to query Checkouts too, and they payload is quite different, which is probably why there are 2 different APIs. I'm seeing that the line items there do have both a Key and and Id, with the same string value. Very confusing as I said! If we get to implement the Checkout API, it will need its own class because they have different properties. I would suggest renaming the current Checkout class to AbandonedCheckout. And also CheckoutLineItem to AbandonedCheckoutLineItem so that we can use the current names for the actual Checkout API.
Yikes, that sounds like a mess. Thanks for investigating!
Do you have a branch for 5.0?
I need the "live" checkouts for a project I'm working on, so I'm going to implement two classes for LiveCheckout
and LiveCheckoutLineItem
since they don't have the same props as the abandoned checkout we have implemented. In 5.0 we'll have to rename Checkout
to AbandonedCheckout
. I'm planning on starting 5.0 toward the end of May.
Hey @nozzlegear !
will this get fixed? and if not how can I change id to string without using the source code? I mean I want to use the package as a nuget package and not having to update the source code all the time..??
Hey @nlevos! To be honest I haven't really decided what to do with this and haven't put much thought into it since I haven't had to experience it myself. Do we know for sure that this is now a string? Is it in the docs? If it's only a string in some cases and long in others, I suppose the best and fastest solution would be to just set the type to an object.
Hi @nozzlegear !
I didn't have a problem until now.. I have being getting data from more than 50 stores.. But now I run into this problem on a big store that I am trying to get data from..
So, yes, if you can, please switch to object and we can cast per case.. This will solve it for now..
Just so you know, id comes like a guid string..
Let me know whatever you do!
Thanks a lot! Nikos
Hey @nozzlegear!
I'm struggling with this one too - any idea when/if this will make it in to a release? Same issue as described above with the id not being long.
Well I havent had any problems doing this with the code:
using Newtonsoft.Json; using ShopifySharp.Enums; using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; namespace ShopifySharp { public class CheckoutLineItem : LineItem { /// <summary> /// The key for the line item. /// </summary> [JsonProperty("key")] public string Key { get; set; } /// <summary> /// The unique numeric identifier for the product in the fulfillment. Can be null if the original product associated with the order is deleted at a later date /// </summary> [JsonProperty("origin_location_id")] public long? OriginLocationId { get; set; } [JsonProperty("id")] public new string Id { get; set; } } }
I was able to get checkouts without any problems for over 600 clients.
@colbydilks have you tried this temporary fix? Surprised it hasnt been fixed yet..