Tictactoe notifications not displaying in generated app

[jholleran]

Describe the bug
I have setup two Pods, (User 1) and (User 2). User 1 creates a tictactoe game for User 2. When I log in a User 2 I don't get an notification that the game has been created.

To Reproduce
Steps to reproduce the behavior:

1. Register User 1
2. Register User 2
3. User 1 creates a game to User 2
4. Login as User 2 and check for notifications

Expected behavior
A notification should be displayed in the top right corner of the screen and when you click it it should display the notifications in a list.

Screenshots
N/A

Desktop (please complete the following information):

• OS: Ubuntu
• Browser Chrome
• Version 78.0.3904.97 (Official Build) (64-bit)

Smartphone (please complete the following information):
N/A

Additional context
The requests in the Network tab are all ok (No 404 errors). The only error I see is:
index.js:23236 Uncaught (in promise) Error: Expected entity but got literal on line 1.
at u.value (index.js:23236)
at u.value (index.js:22826)
at u.value (index.js:22854)
at index.js:23321
at Array.every ()
at u.value (index.js:23320)
at index.js:101678
at w (index.js:46479)
at Generator._invoke (index.js:46459)
at Generator.e. [as next] (index.js:46498)
at p (index.js:92343)
at a (index.js:92360)

Also, I noticed that when there is a GET request to the tictactoe inbox the response is JSONLD:

{"@id":"http://localhost:8000/tom/public/games/tictactoe/inbox","contains":["http://localhost:8000/tom/public/games/tictactoe/inbox/1574256847099","http://localhost:8000/tom/public/games/tictactoe/inbox/.acl"],"@context":{"contains":{"@id":"http://www.w3.org/ns/ldp#contains","@type":"@id"},"schema":"http://schema.org/","a":"http://www.w3.org/ns/auth/acl#type","solid":"http://www.w3.org/ns/solid/terms#","owl":"http://www.w3.org/2002/07/owl#","xsd":"http://www.w3.org/2001/XMLSchema#","skos":"http://www.w3.org/2004/02/skos/core#","rdfs":"http://www.w3.org/2000/01/rdf-schema#","acl":"http://www.w3.org/ns/auth/acl#","n":"http://www.w3.org/2006/vcard/ns#","geo":"http://www.w3.org/2003/01/geo/wgs84_pos#","dc11":"http://purl.org/dc/elements/1.1/","as":"https://www.w3.org/ns/activitystreams#","rdf":"http://www.w3.org/1999/02/22-rdf-syntax-ns#","terms":"http://purl.org/dc/terms#","ldp":"http://www.w3.org/ns/ldp#","time":"http://www.w3.org/2006/time#","ws":"http://www.w3.org/ns/pim/space#","prov":"http://www.w3.org/ns/prov#","foaf":"http://xmlns.com/foaf/0.1/","dc":"http://purl.org/dc/terms/"}}

The request header for the GET request has the following:

accept: application/n-quads,application/trig;q=0.95,application/ld+json;q=0.9,application/n-triples;q=0.8,text/turtle;q=0.5,*/*;q=0.1

As you can see it has application/ld+json before text/turtle.

If the SDK generator does not support JSONLD it should not have this in the Accept header.

[RubenVerborgh]

Related: LDflex/Solid-Playground#8

[RubenVerborgh]

If the SDK generator does not support JSONLD

But this request is not being made by the SDK generator; it is made by LDflex, which supports JSON-LD.

Expected entity but got literal on line 1.

This looks like a parser error from N3.js (not entirely sure). Someone is trying to parse the JSON-LD document as Turtle.

Could you please produce a stack trace with a source map, so we can find out who that is?

[RubenVerborgh]

Or is the server lying and presenting the JSON-LD with Content-Type: text/turtle?

[james-martin-jd]

For what it's worth, the SDK does assume it's a ttl response right now. I suppose it's possible if it's returning json-ld, the SDK code is attempting to use N3.js to parse something (most likely notifications) and hitting an error at that point. It sounds like we need a way to force accept: text/turtle instead of json-ld?

[RubenVerborgh]

Yeah but the question is: who issues the request? If LDflex issues the request, then LDflex is responsible for parsing, and it is sending the correct headers. If the SDK is responsible for the request, then the SDK controls the Accept header.

If both are fetching the same document, but the server sends improper Vary headers, then the above can also happen.

[RubenVerborgh]

Could I get all request and response headers please?

[jholleran]

GET http://localhost:8000/tom/public/games/tictactoe/inbox/

Request Headers:

accept: application/n-quads,application/trig;q=0.95,application/ld+json;q=0.9,application/n-triples;q=0.8,text/turtle;q=0.5,/;q=0.1
Origin: http://localhost:3000
Referer: http://localhost:3000/welcome
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.97 Safari/537.36

Response Headers:

Accept-Patch: application/sparql-update
Accept-Post: text/turtle,application/ld+json,application/n-triples,/
access-control-allow-credentials: true
access-control-allow-origin: http://localhost:3000
Allow: GET,HEAD,OPTIONS,PATCH,PUT,DELETE,POST
Cache-Control: must-revalidate, no-transform, max-age=86400
Content-Type: application/ld+json
ETag: W/"5cd9d3e4c940139756122458b575f113"
Last-Modified: Wed, 20 Nov 2019 13:34:07 GMT
Link: <http://www.w3.org/ns/ldp#BasicContainer>; rel="type"
Link: <http://www.w3.org/ns/ldp#Container>; rel="type"
Link: <http://www.w3.org/ns/ldp#RDFSource>; rel="type"
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Link: <http://localhost:8000/tom/public/games/tictactoe/inbox>; rel="original timegate"
Link: <http://localhost:8000/tom/public/games/tictactoe/inbox>; rel="self"
Link: <http://localhost:8000/tom/public/games/tictactoe/inbox/?ext=acl>; rel="acl"
Vary: Accept,Accept-Datetime,Prefer

[RubenVerborgh]

The above headers are correct (with the exception of Vary not including Origin, but not a problem for our purposes).

[RubenVerborgh]

So I'd need the source-mapped stack trace.

[james-martin-jd]

The same call against NSS shows the accept headers as */* instead. Not sure if that is significant or not.

[jaxoncreed]

When you send an OPTIONS request to ESS what does it return as it's supported content types?

[RubenVerborgh]

Just want to add here that the Accept header sent by the client does not / should not depend on the server. The client just states what it supports; regardless of what the server has to offer.

[jholleran]

Yesterday, I configured the server only return turtle and the JS error went away. But the Notifications were still not working. So it looks to be some other issue than the JS error I reported above that is causing this.

Today, for some strange reason, I don't see the JS error even though the server is back returning JSON-LD.

We are still debugging this here an I will send on any update.

@james-martin-jd what do ye do to debug the solid-react-components components?

[james-martin-jd]

@jholleran there's actually a Demo application in the repo, if you clone it and then npm run start in the root it spins up a demo app. The app runs on the App.js file, and is a VERY rudimentary page just designed to throw raw components or class calls in there.

[james-martin-jd]

So, after a lot of debugging, I believe this was a bug in the code where we had mismatched PUT vs slug header values. The PUT was to notificationName.ttl with a slug of notificationName. I've corrected this so the PUT does not have a slug anymore, although it still does say .ttl I am told this should not affect ESS one way or the other, just looks weird. I have an open ticket to improve this even more.

@jholleran is it possible for you to test this against ESS?