researchstudio-sat / webofneeds

Finding people to cooperate with. Protocol, not platform. Decentralized. Linked Data. Open Source.
http://researchstudio-sat.github.io/webofneeds/
Apache License 2.0
62 stars 20 forks source link

Endless loading loop when loading conversation #3062

Closed fkleedorfer closed 4 years ago

fkleedorfer commented 5 years ago

I have a conversation between two of my atoms, for testing purposes. it used to work normally, but now, opening either side of the connection in the chats view leads to an endless loading loop.

The following four resources are polled eternally:

https://www.matchat.org/owner/rest/linked-data/?requester=https:%2F%2Fnode.matchat.org%2Fwon%2Fresource%2Fatom%2Fddkzn14jqzbn&uri=https:%2F%2Fnode.matchat.org%2Fwon%2Fresource%2Fconnection%2Fb32gb5ymcsqvi8uktl4e%3Fdeep%3Dtrue
https://www.matchat.org/owner/rest/linked-data/?requester=https:%2F%2Fnode.matchat.org%2Fwon%2Fresource%2Fatom%2Fg6vzhkqqogv9&uri=https:%2F%2Fnode.matchat.org%2Fwon%2Fresource%2Fconnection%2Fmusb45osnkgrwyvfw1lg%3Fdeep%3Dtrue
https://www.matchat.org/owner/rest/linked-data/?requester=https:%2F%2Fnode.matchat.org%2Fwon%2Fresource%2Fatom%2Fmlroxk7jfy68&uri=https:%2F%2Fnode.matchat.org%2Fwon%2Fresource%2Fconnection%2Fio0c2gtnu9fi0atkzf3l%3Fdeep%3Dtrue
https://www.matchat.org/owner/rest/linked-data/?requester=https:%2F%2Fnode.matchat.org%2Fwon%2Fresource%2Fatom%2Fzni5rhdzwnp7&uri=https:%2F%2Fnode.matchat.org%2Fwon%2Fresource%2Fconnection%2Fdsqetywi9uw707zhgnll%3Fdeep%3Dtrue

The requests get a 304 response and are served from the browser cache.

When making the window small enough, you also see that the content of the chat panel gets redrawn and then re-scrolled every time the connection or atom loads.

Happens in FF as well as Chrome. Here's a js stack trace of where the request is made:

D | @ | linkeddata-service-won.js:712
-- | -- | --
  | (anonymous) | @ | linkeddata-service-won.js:505
  | tryCatch | @ | runtime.js:45
  | invoke | @ | runtime.js:271
  | prototype.<computed> | @ | runtime.js:97
  | p | @ | linkeddata-service-won.js:1809
  | i | @ | linkeddata-service-won.js:1809
  | Promise.then (async) |   |  
  | p | @ | linkeddata-service-won.js:1809
  | i | @ | linkeddata-service-won.js:1809
  | (anonymous) | @ | linkeddata-service-won.js:1809
  | (anonymous) | @ | linkeddata-service-won.js:1809
  | (anonymous) | @ | linkeddata-service-won.js:466
  | a.default.getNode | @ | linkeddata-service-won.js:1260
  | a.default.getConnectionWithEventUris | @ | linkeddata-service-won.js:1158
  | O | @ | state-store.js:267
  | (anonymous) | @ | connections-actions.js:709
  | (anonymous) | @ | index.js:9
  | (anonymous) | @ | router-middleware.js:40
  | showLatestMessages | @ | topnav.jsx:62
  | (anonymous) | @ | topnav.jsx:222
  | (anonymous) | @ | immutable.js:3016
  | (anonymous) | @ | immutable.js:1377
  | Nt.iterate.Vt.iterate | @ | immutable.js:1726
  | Tt.__iterate | @ | immutable.js:1375
  | Be.n.__iterateUncached | @ | immutable.js:3015
  | ht | @ | immutable.js:604
  | V.__iterate | @ | immutable.js:274
  | forEach | @ | immutable.js:4381

I am not sure how anyone can reproduce this, but at least with this connection, I can.

quasarchimaere commented 4 years ago

pretty sure this was a bug that happened when the fetched "visible" messages where below the threshold that prevented the loadLatestMessages from happening, and thus loaded the latest x messages endlessly... should be fixed for a while already, closing this issue