Curious 400 error when removing using Inrupt

Hi, I’ve got a method that eventally reaches a section like this:

const updatedDataset = removeThing(this.dataset, habit);
console.log(solidDatasetAsMarkdown(updatedDataset));
console.log(changeLogAsMarkdown(updatedDataset));
await saveSolidDatasetAt(getSourceUrl(this.dataset), updatedDataset, { fetch: this.session.fetch });

habit here is a Thing retrieved from the dataset using getThing. My dataset looks like this:

@prefix : <#>.
@prefix ex: <http://example.com/>.
@prefix ic: <http://www.w3.org/2002/12/cal/ical#>.
@prefix XML: <http://www.w3.org/2001/XMLSchema#>.
@prefix schem: <https://schema.org/>.

:161721840909105701640716636325
    a ex:habit_itm;
    ic:created "2021-03-31T19:20:09.091Z"^^XML:dateTime;
    schem:text "Item 1".
:16172184128225402754458653447
    a ex:habit_itm;
    ic:created "2021-03-31T19:20:12.822Z"^^XML:dateTime;
    schem:text "Item 2".
:161721841572814167595175896774
    a ex:habit_itm;
    ic:created "2021-03-31T19:20:15.728Z"^^XML:dateTime;
    schem:text "Item 3".

My goal is to remove one of these, for instance Item 2. From my understanding, I need to provide the UrlString of Item 2 to removeThing and get back a new dataset that has everything except Item 2. I check this by logging the markdown of the new dataset and its changes, and confirm that it has worked:

solidDatasetAsMarkdown

SolidDataset: https://etscevhq.inrupt.net/habits2/index.ttl

Thing: https://etscevhq.inrupt.net/habits2/index.ttl#161721840909105701640716636325

Property: http://www.w3.org/1999/02/22-rdf-syntax-ns#type

  • <http://example.com/habit_itm> (URL)

Property: http://www.w3.org/2002/12/cal/ical#created

  • Wed, 31 Mar 2021 19:20:09 GMT (datetime)

Property: https://schema.org/text

  • “Item 1” (string)

(0 new values added / 0 values removed)

Thing: https://etscevhq.inrupt.net/habits2/index.ttl#161721841572814167595175896774

Property: http://www.w3.org/1999/02/22-rdf-syntax-ns#type

  • <http://example.com/habit_itm> (URL)

Property: http://www.w3.org/2002/12/cal/ical#created

  • Wed, 31 Mar 2021 19:20:15 GMT (datetime)

Property: https://schema.org/text

  • “Item 3” (string)

(0 new values added / 0 values removed)

changeLogAsMarkdown

Changes compared to https://etscevhq.inrupt.net/habits2/index.ttl

Thing: https://etscevhq.inrupt.net/habits2/index.ttl#16172184128225402754458653447

Property: http://www.w3.org/1999/02/22-rdf-syntax-ns#type

  • Removed:
    • <http://example.com/habit_itm> (URL)

Property: http://www.w3.org/2002/12/cal/ical#created

  • Removed:
    • Wed, 31 Mar 2021 19:20:12 GMT (datetime)

Property: https://schema.org/text

  • Removed:
    • “Item 2” (string)

Perfect! Now I just need to run saveSolidDatasetAt to save this, right? Apparently not…

I am new to Solid, is there something that I am missing?

Hi @awpap1, welcome to the Solid forum! On first sight, that looks like a bug in solid-client to me. I’ve reported it here and will investigate. If the code you’re working on is open source, it’d be great if you could share.

1 Like

Thanks. I don’t think I am allowed to open-source the code yet, but I will in the future. Is there a temporary workaround I could use to accomplish what I am trying to achieve?

I’m not sure yet; I’m trying to reproduce it as we speak, and will let you know when I have more info.

Hi @awpap1, I think I have identified the source of the bug, which seems to have been introduced with the latest release of one of solid-client’s dependencies.

I have prepared a quick fix, could you attempt to install that using

    npm install @inrupt/solid-client@fix957-400-on-put

and report back whether that solves it for you?

Thank you! This has fixed it. I have created a public reproduction at GitHub - e1019/solid-ui-react-example-project but you beat me to it.

I noticed the error does not happen if remove_thing (components/profile/index.tsx:122) accepts a Thing and the Button onClick passes the Thing directly, but if I change it such that it accepts a URL and I pass the Thing’s URL, the error happens.

2 Likes

Glad to hear, and thanks for the reproduction! We’ll create a new release including the fix ASAP.

1 Like

Last week I pinned the version of the dependency after whose update the bug was introduced, which gave me some breathing room. I have now identified the root cause, so that it no longer will happen with newer versions of that dependency, and which is consistent with the behaviour you described w.r.t. passing a URL or a Thing. All of that was made easier by your detailed report, so I just wanted to reach out again and say thanks for that :slight_smile: