Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AT: API response for i_like and like_count status for comments can get out of sync. #76444

Closed
worldomonation opened this issue May 1, 2023 · 4 comments
Labels
Needs triage Ticket needs to be triaged [Platform] Atomic [Pri] Low Address when resources are available. [Type] Bug

Comments

@worldomonation
Copy link
Contributor

worldomonation commented May 1, 2023

Quick summary

Upon querying the endpoint /sites/{site_id}/comments/{comment_id}/likes/new on AT sites, the values returned in the response can sometimes be out of sync and thus objectively wrong.

Important context: #76414 (comment).

Steps to reproduce

All steps are executed using a script, not by hand (eg. NodeJS script or a E2E spec).

  1. post a new comment on a site.
  2. like the comment as the posting (same) user.

What you expected to happen

Response from the API should state the following:

{
  "success": true,
  "i_like": true,
  "like_count": 1,
  "meta": {
       ...
  }

What actually happened

Sometimes, the API responds as follows:

{
  "success": true,
  "i_like": true,
  "like_count": 0,
  "meta": {
       ...
  }

Notice the like_count stuck at 0, in contradiction to the i_like line above the count.

Impact

One

Available workarounds?

Yes, easy to implement

Platform (Simple and/or Atomic)

Atomic, Self-hosted

Logs or notes

No response

Related: #75952, #76414

@worldomonation
Copy link
Contributor Author

Slack: p1682922721277819-slack-C7YPW6K40

@worldomonation
Copy link
Contributor Author

I re-ran the spec likes__comments.ts and looked into Logstash logs to see if any nginx errors are created (as stated in P9o2xV-30n-p2).

I've summarized the findings in p1684733096963739/1682922721.277819-slack-C7YPW6K40, but the gist is that contrary to what is written in the P2, nginx view in Logstash did not report anything for the affected site ID in the timeframe.

Because there were at least 10 failed attempts by the RestAPIClient to "like" the comment, there should have been at least 10 errors logged in nginx. I did not find any errors however (see the screenshot in the thread).

@worldomonation
Copy link
Contributor Author

While I was able to look at the right logstash views, I am no closer to identifying the root cause of this issue.

Putting it on hold because it has been discussed that this particular test (and many other highly intermittent tests) have low value, and may end up being deleted.

@jordesign
Copy link
Contributor

Closing this as it was a task from a team that is now discontinued.

@jordesign jordesign closed this as not planned Won't fix, can't repro, duplicate, stale Jan 14, 2025
@github-project-automation github-project-automation bot moved this from Backlog to Done🎊 in KitKat Project Board Jan 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs triage Ticket needs to be triaged [Platform] Atomic [Pri] Low Address when resources are available. [Type] Bug
Projects
Status: Done🎊
Development

No branches or pull requests

3 participants