🐛 [Bug report]: Filter by Play Creator fails

[atapas]

Descrcibe the bug?

When we filter plays by multiple creators, it returns all the plays.

Steps to reproduce the bug?

• go to the play list page
• Click on the filter icon.
• Add two creator names in the filter criteria
• Appy
• It results in all the plays

Expected behavior

It should result the plays created by the users selected. in

Desktop (Please provide your system information)

All

Mobile (Please provide your device information)

No response

Screenshot / Screenshare

No response

Relevant log output

No response

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[atapas]

Hey @supminn Can you check this issue?

[mayukh551]

@atapas can I work on this issue?

[atapas]

@atapas can I work on this issue?

Done

[mayukh551]

Great! I am on it...

[mayukh551]

@atapas I tried to recreate this issue, but looks like it is working fine and showing the desired filtered result when I run this locally.

https://user-images.githubusercontent.com/82811112/211800943-3674ab68-04e2-442f-a853-8c1df7ebd565.mp4

[atapas]

@atapas

I tried to recreate this issue, but looks like it is working fine and showing the desired filtered result when I run this locally.

https://user-images.githubusercontent.com/82811112/211800943-3674ab68-04e2-442f-a853-8c1df7ebd565.mp4

Can you please try it on production?

[mayukh551]

@atapas Just a small confusion when you say to try it on production... Should I create a PR linked to this issue and then you deploy it on for preview? Or Should I create a build folder using build command and then deploy react-play myself to Vercel?

[supminn]

Hey @atapas I took the latest pull from the main branch and tested it out, the feature seems to be working. Do we have any release branch which is deployed on production or is it synced with main branch?

[atapas]

Hi @supminn and @mayukh551

Production means https://reactplay.io, and you do not need to create any PR. Try reproducing the issue there.

The production is running from the main branch. Not from any release branches. Please let me know if it is reproducible for you both on the production.

[supminn]

Yes @atapas, I am able to reproduce the issue on production. However, when I refer to the local deployment using the main branch, the functionality is working fine. Please help us understand how we could test this issue locally.

[mayukh551]

@atapas Same here. Was able to reproduce the problem on production. But works fine on localhost.

[atapas]

It's strange for me too, folks. I will suggest you capture the network calls for both local and prod on this operation. Find what's the diff of the call and responses. That will give us the clue.

[mayukh551]

It's strange for me too, folks. I will suggest you capture the network calls for both local and prod on this operation. Find what's the diff of the call and responses. That will give us the clue.

I checked the network tab in dev tools, On production: After I applied the multiple filter tags of creators on the network tab, graphQL response is all the plays created till date

while on Local host, graphQL response data is as expected, i.e only what is asked based on the filters.

[atapas]

It's strange for me too, folks. I will suggest you capture the network calls for both local and prod on this operation. Find what's the diff of the call and responses. That will give us the clue.

I checked the network tab in dev tools,

On production:

After I applied the multiple filter tags of creators

on the network tab, graphQL response is all the plays created till date

while on Local host, graphQL response data is as expected, i.e only what is asked based on the filters.

How about the request and payload? Are they same?

[mayukh551]

@atapas No payload is different

on Production payload is: query Fetch_Plays { plays( order_by: { created_at: desc } where: { _and: [ { dev_mode: { _eq: false } } { _or: [ { dev_mode: { _eq: false } } { owner_user_id: { _eq: "0680f581-6584-4bc4-bbe9-aa7c97567e72" } } { owner_user_id: { _eq: "4fa14525-8f98-45b9-9a8b-c1ba34c6ed43" } } ] } ] } ) { component cover description featured dev_mode github language play_like { liked play_id user_id } name slug user { id displayName avatarUrl } created_at } }

on local host:

query Fetch_Plays { plays( order_by: { created_at: desc } where: { _and: { _or: [ { owner_user_id: { _eq: "4fa14525-8f98-45b9-9a8b-c1ba34c6ed43" } } { owner_user_id: { _eq: "0680f581-6584-4bc4-bbe9-aa7c97567e72" } } ] } } ) { component cover description featured dev_mode github language play_like { liked play_id user_id } name slug user { id displayName avatarUrl } created_at } }

[mayukh551]

I also noticed that Request url sent for graphql response to nhost are different for localhost and production bcoz of an extra slash local => request url: https://rgkjmwftqtbpayoyolwh.nhost.run//v1/graphql

production => request url: https://rgkjmwftqtbpayoyolwh.nhost.run/v1/graphql

[atapas]

I also noticed that Request url sent for graphql response to nhost are different for localhost and production bcoz of an extra slash local => request url: https://rgkjmwftqtbpayoyolwh.nhost.run//v1/graphql

production => request url: https://rgkjmwftqtbpayoyolwh.nhost.run/v1/graphql

This should not make a difference, IMO.

[mayukh551]

Ok

[atapas]

@supminn @mayukh551

CC: @koustov

"Kahani me Twist(Twist in the tale)" --> It works perfectly on the preview build(that's on Vercel). Here is an example: https://react-play-git-fork-mayukh551-leaderboad-ui-reactplayio.vercel.app/plays

So it fails only on Netlify, where our prod code runs. So, that's a clue we have.

Thoughts?

[supminn]

@atapas @mayukh551 I went through both the API calls' payloads to check the difference. There has been a condition to check { dev_mode: { _eq: false } } which has been incorrectly added twice. Thus, this issue is occurring.

If we remove the { dev_mode: { _eq: false } } code within the _or block, we get the desired results. I am working on the fixes.

[supminn]

I have created the PR and its ready for review - https://github.com/reactplay/react-play/pull/872 cc: @atapas @mayukh551