starred/hoppscotch

Fork 0

mirror of https://github.com/hoppscotch/hoppscotch.git synced 2026-04-26 01:06:00 +03:00

[GH-ISSUE #4395] [bug]: Missing status in GraphQL requests #1606

New issue

Closed

opened 2026-03-16 21:04:21 +03:00 by kerem · 11 comments

kerem commented

2026-03-16 21:04:21 +03:00

Owner

Originally created by @rb090 on GitHub (Oct 1, 2024).
Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/4395

Originally assigned to: @barrettluke on GitHub.

Is there an existing issue for this?

I have searched the existing issues

Current behavior

When firing a GraphQL request the Http Status is missing in the UI:

When firing a REST request the request status is displayed beautifully:

Can this behaviour for GraphQL request be turned on and off somewhere?

Steps to reproduce

Go to https://hoppscotch.io/graphql
Click "Request"
Response looking like this:

Environment

Production

Version

Local

Originally created by @rb090 on GitHub (Oct 1, 2024). Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/4395 Originally assigned to: @barrettluke on GitHub. ### Is there an existing issue for this? - [X] I have searched the existing issues ### Current behavior When firing a GraphQL request the Http Status is missing in the UI: ![Screenshot 2024-10-01 at 18 21 44](https://github.com/user-attachments/assets/172cc3a0-9241-4af4-bebc-992c691922df) When firing a REST request the request status is displayed beautifully: <img width="1263" alt="Screenshot 2024-10-01 at 18 21 24" src="https://github.com/user-attachments/assets/fc95ee14-9f9e-473d-a199-a298a4865e9c"> Can this behaviour for GraphQL request be turned on and off somewhere? ### Steps to reproduce 1. Go to https://hoppscotch.io/graphql 2. Click "Request" 3. Response looking like this: ![Screenshot 2024-10-01 at 18 28 45](https://github.com/user-attachments/assets/17977db1-60b6-44c0-bad4-b4fb4acc2728) ### Environment Production ### Version Local

kerem

2026-03-16 21:04:21 +03:00

closed this issue
added the
bug

need testing
labels

kerem commented

2026-03-16 21:04:37 +03:00

Author

Owner

@barrettluke commented on GitHub (Oct 2, 2024):

I would like to work on this.

@barrettluke commented on GitHub (Oct 2, 2024): I would like to work on this.

kerem commented

2026-03-16 21:04:42 +03:00

Author

Owner

@nivedin commented on GitHub (Oct 3, 2024):

@barrettluke assigning this to you

@nivedin commented on GitHub (Oct 3, 2024): @barrettluke assigning this to you

kerem commented

2026-03-16 21:04:47 +03:00

Author

Owner

@rb090 commented on GitHub (Oct 3, 2024):

Thank you so much, I really appreciate your help with this. If there is sth I can help with, please let me know. I am using atm the AIO container of the hoppscotch community edition. So can that one please get a new release with this fix once it is done?

We host hoppscotch on our side with that Docker container.

@rb090 commented on GitHub (Oct 3, 2024): Thank you so much, I really appreciate your help with this. If there is sth I can help with, please let me know. I am using atm the [AIO container](https://docs.hoppscotch.io/documentation/self-host/community-edition/install-and-build) of the hoppscotch community edition. So can that one please get a new release with this fix once it is done? We host hoppscotch on our side with that Docker container.

kerem commented

2026-03-16 21:04:52 +03:00

Author

Owner

@Narasimha677 commented on GitHub (Oct 6, 2024):

hey @barrettluke , can i know are u still working on this issue?

@Narasimha677 commented on GitHub (Oct 6, 2024): hey @barrettluke , can i know are u still working on this issue?

kerem commented

2026-03-16 21:04:57 +03:00

Author

Owner

@barrettluke commented on GitHub (Oct 7, 2024):

@Narasimha677 yes I am still working on this.

@barrettluke commented on GitHub (Oct 7, 2024): @Narasimha677 yes I am still working on this.

kerem commented

2026-03-16 21:05:02 +03:00

Author

Owner

@barrettluke commented on GitHub (Oct 10, 2024):

Should this show up when Connect button is pressed or a connections is made or should this show up when Request button is pressed and query is sent?

@barrettluke commented on GitHub (Oct 10, 2024): Should this show up when Connect button is pressed or a connections is made or should this show up when Request button is pressed and query is sent?

kerem commented

2026-03-16 21:05:07 +03:00

Author

Owner

@rb090 commented on GitHub (Oct 10, 2024):

I would like to see it when the GraphQL request was send and we got a response from the GQL server. So basically like it is for REST requests 🙂. Like this when sending GQL requests in P*****n 🙈.

@rb090 commented on GitHub (Oct 10, 2024): I would like to see it when the GraphQL request was send and we got a response from the GQL server. So basically like it is for REST requests 🙂. Like this when sending GQL requests in P*****n 🙈.

kerem commented

2026-03-16 21:05:12 +03:00

Author

Owner

@barrettluke commented on GitHub (Oct 11, 2024):

After reviewing the code, I noticed that RequestRunner.ts—specifically the runRESTRequest$ function—is specific for REST requests. Given this, I don’t think it should be used for GraphQL queries as-is.

If a new file or function is needed to handle the checks for GraphQL requests, a key question is: how should the response object look? Should the new data be integrated into the current GraphQL response, or would it make more sense to nest it within the existing structure? Additionally, how much data would you like returned? Should we limit it to the status code, response time (ms), and size, or should we include all the data returned by an HTTP response?

It seems like there are a few important questions to address, and this could potentially become part of a larger task. An alternative could be to quickly implement a basic solution with a curl request, but I don’t think that would be ideal for maintainability.

@barrettluke commented on GitHub (Oct 11, 2024): After reviewing the code, I noticed that RequestRunner.ts—specifically the runRESTRequest$ function—is specific for REST requests. Given this, I don’t think it should be used for GraphQL queries as-is. If a new file or function is needed to handle the checks for GraphQL requests, a key question is: how should the response object look? Should the new data be integrated into the current GraphQL response, or would it make more sense to nest it within the existing structure? Additionally, how much data would you like returned? Should we limit it to the status code, response time (ms), and size, or should we include all the data returned by an HTTP response? It seems like there are a few important questions to address, and this could potentially become part of a larger task. An alternative could be to quickly implement a basic solution with a curl request, but I don’t think that would be ideal for maintainability.

kerem commented

2026-03-16 21:05:17 +03:00

Author

Owner

@rb090 commented on GitHub (Oct 11, 2024):

Oh no, I am sorry that this causes so much complexity. For my team and me this would be really a super helpful functionality 😢.

how should the response object look? Should the new data be integrated into the current GraphQL response, or would it make more sense to nest it within the existing structure?

I guess that is a question on the hoppscotch code?

The HTTP status code is an attribute outside the GQL response from the server point of view:

Additionally, how much data would you like returned? Should we limit it to the status code, response time (ms), and size?

That would be super helpful tbh. And make us more than happy.

... should we include all the data returned by an HTTP response?

If server returns a response on a failed GQL request, this response is already visible in the UI and this is super cool.

Other data like fe. response headers would be not so important for us.

@rb090 commented on GitHub (Oct 11, 2024): Oh no, I am sorry that this causes so much complexity. For my team and me this would be really a super helpful functionality 😢. > how should the response object look? Should the new data be integrated into the current GraphQL response, or would it make more sense to nest it within the existing structure? I guess that is a question on the hoppscotch code? The HTTP status code is an attribute outside the GQL response from the server point of view: ![Screenshot 2024-10-11 at 09 20 27](https://github.com/user-attachments/assets/e9ff15de-bfea-4308-90b8-0c891c2c1047) > Additionally, how much data would you like returned? Should we limit it to the status code, response time (ms), and size? That would be super helpful tbh. And make us more than happy. > ... should we include all the data returned by an HTTP response? If server returns a response on a failed GQL request, this response is already visible in the UI and this is super cool. ![Screenshot 2024-10-11 at 09 27 01](https://github.com/user-attachments/assets/298cdcfc-4e10-4247-8c06-3c8198475d8d) Other data like fe. response headers would be not so important for us.

kerem commented

2026-03-16 21:05:22 +03:00

Author

Owner

@ToshY commented on GitHub (Jan 1, 2025):

I'm experiencing the same problem. Is there any hold-up with the existing PR #4435 ?

@ToshY commented on GitHub (Jan 1, 2025): I'm experiencing the same problem. Is there any hold-up with the existing PR #4435 ?

kerem commented

2026-03-16 21:05:27 +03:00

Author

Owner

@liyasthomas commented on GitHub (Jul 30, 2025):

This issue has been resolved in the latest version.

@liyasthomas commented on GitHub (Jul 30, 2025): This issue has been resolved in the latest version.