talk icon indicating copy to clipboard operation
talk copied to clipboard

Comment replies not shown when watching specific conversation thread

Open ShittyAdvice opened this issue 1 year ago • 2 comments
trafficstars

Expected behavior: When I 'deeplink' to a specific comment I see the single conversation thread and I expect to see all the replies to the linked comment. When a reply to a comment is created I'd expect that comment or stories cache to get invalidated

Actual behavior: The replies are not shown. Only the parent comments are shown. The html element for <PermaLinkViewContainer> is empty and the graphql responds with an empty list for the replies.

After recaching the whole article these replies are now shown when viewing a single conversation thread. It seems like the replies are being cached initially but never updated when there is a reply even though on the main thread these replies were already visible without recaching the article.

Question: Why can I see all the replies on the main thread, but not in a single conversation? Is there a desync in this cache or am I missing something obvious?

Related Issues: No similar issues found

Versions:

  • Coral: 9.0.1
  • NodeJS: 18.16
  • NPM: 9.5.1
  • MongoDB: 5.0.5
  • Redis: 3.2
  • Browser: Brave - Chromium
  • OS: MacOS

Reproduction

  1. Remove featureFlag DATA_CACHE
  2. Reply to a comment and then reply to that comment.
  3. Comments are shown when reloading talk.
  4. Copy link of the middle comment and navigate to it -> You'll see the parent comment and replies.
  5. Enable featureFlag DATA_CACHE and refresh the page. You will see the parent comment, but no replies.
  6. Go to admin interface and choose to recache the story -> The missing replies now appear, but this has to be done everytime new replies are added

ShittyAdvice avatar May 01 '24 08:05 ShittyAdvice

Thanks, we'll look into it.

losowsky avatar May 01 '24 13:05 losowsky

To add to this: It seems like if you've pressed recache story once after that it stays up to date with the replies automatically and you don't need to press it every time, just once after an article is initially created.

We made a temporary work around that we do a cacheStory call after our createStory call, but I'd expect this to not be needed and it feels like something is missing on both existing and new articles where recache has never been pressed

ShittyAdvice avatar May 01 '24 16:05 ShittyAdvice

This is fixed now, thanks!

losowsky avatar Jun 04 '24 16:06 losowsky