INSERT DATA Request appears to remove existing data in a resource

[jeswr]

Issue type:

• 🐛 Bug

---

Description:

If I run the following script against the CSS at localhost:3000 then the result of the final CONSTRUCT query is just <ex:s> <ex:p> <ex:o2> when I would expect 3 triples; namely

<ex:s> <ex:p> <ex:o1>, <ex:o1.1>, <ex:o2>.

import { QueryEngine } from '@comunica/query-sparql-solid';
import { interactiveLogin } from 'solid-node-interactive-auth';
import cliSelect from 'cli-select';

async function getOidcIssuer() {
  console.log('Please select oidcIssuer:')
  const value = await cliSelect({
    values: [
      'https://login.inrupt.com/',
      'http://localhost:3000/'
    ]
  });
  if (!value) {
    throw new Error('Expected string');
  }
  return value.value;
}

async function main() {
  const myEngine = new QueryEngine();
  const oidcIssuer = await getOidcIssuer();
  const session = await interactiveLogin({ oidcIssuer });

  const bindings = await myEngine.queryBindings(`SELECT ?o WHERE { <${session.info.webId!}> <http://www.w3.org/ns/pim/space#storage> ?o }`, {
    sources: [ session.info.webId! ],
    '@comunica/actor-http-inrupt-solid-client-authn:session': session,
  });

  const bindingsArray = await bindings.toArray();

  let storage =
    // For ESS use pim:storage
    bindingsArray[0]?.get('o')?.value!
    // For CSS use webid with /profile/card#me stripped (hacky)
    || session.info.webId!.replace(/profile\/card\#me$/, '');


  const resource = `${storage}test-${Date.now()}.ttl`;

  // Create test.ttl (did not exist before)
  await myEngine.queryVoid(`INSERT DATA { <ex:s> <ex:p> <ex:o1> . <ex:s> <ex:p> <ex:o1.1> }`, {
    sources: [ resource ],
    '@comunica/actor-http-inrupt-solid-client-authn:session': session,
  });

  // Modify existing test.ttl
  await myEngine.queryVoid(`INSERT DATA { <ex:s> <ex:p> <ex:o2> }`, {
    sources: [ resource ],
    '@comunica/actor-http-inrupt-solid-client-authn:session': session,
  });

  // Get data in resource file
  const quads = await myEngine.queryQuads(`CONSTRUCT { ?s ?p ?o } WHERE { ?s ?p ?o }`, {
    sources: [ resource ],
    '@comunica/actor-http-inrupt-solid-client-authn:session': session,
  });

  console.log(JSON.stringify(await quads.toArray(), null, 2))
  
  await session.logout();
}

main();

---

Environment:

Crash log:

[github-actions]

Thanks for reporting!

[rubensworks]

Looks like something changed in CSS, as this used to work.
Probably related to HTTP headers or some other metadata that makes Comunica think the resource doesn't exist yet, and thereby used POST instead of PATCH.

[jeswr]

I think this change is also causing this package to no longer work against ESS - in particular see:

Error: urn:comunica:default:rdf-update-hypermedia/mediators#main mediated over all rejecting actors:
Actor urn:comunica:default:rdf-update-hypermedia/actors#patch-sparql-update could not detect a destination with 'application/sparql-update' as 'Accept-Patch' header.
Actor urn:comunica:default:rdf-update-hypermedia/actors#put-ldp could not detect a destination with 'Allow: PUT' header.
Actor urn:comunica:default:rdf-update-hypermedia/actors#sparql could not detect a SPARQL service description or URL ending on /sparql or /update.
    at /home/jesse/Documents/github/podspaces-performance-testing/node_modules/@comunica/mediator-race/lib/MediatorRace.js:22:32
    at processTicksAndRejections (node:internal/process/task_queues:96:5)

[rubensworks]

Pinging @joachimvh here as well, perhaps he knows more about changes related to this.

[joachimvh]

Actor urn:comunica:default:rdf-update-hypermedia/actors#patch-sparql-update could not detect a destination with 'application/sparql-update' as 'Accept-Patch' header.

Just did a small check with the default config targeting a resource that does not exist and received a Accept-Patch: text/n3, application/sparql-update header response so the expected header is still there.

Nothing changed regarding SPARQL UPDATE (on purpose at least) for some time.

[rubensworks]

That's interesting. Then the problem lies either in one of our metadata extractors, of the way in which metadata is propagated.

Having some integration tests around this would also be good.

[jeswr]

As a further note this error is also occuring when trying to delete data on a Pod

 Put-based LDP destinations don't support deletions

      44 |
      45 |   public async delete(quads: AsyncIterator<RDF.Quad>): Promise<void> {
    > 46 |     throw new Error(`Put-based LDP destinations don't support deletions`);
         |           ^
      47 |   }
      48 |
      49 |   public async wrapRdfUpdateRequest(type: 'INSERT' | 'DELETE', quads: AsyncIterator<RDF.Quad>): Promise<void>