[GH-ISSUE #4500] [bug]: GraphQL Requests not saved to DB

kerem commented

2026-03-16 21:13:32 +03:00

Owner

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

Is there an existing issue for this?

I have searched the existing issues

Current behavior

When I create a new GraphQL request within a Hoppscotch GraphQL request collection, its content gets not saved properly to the connected database to UserRequest.request into the properties query and variables.

I am running Hoppscotch Community Edition via Docker AIO container on version v2024.9.3. It is connected to a PSQL DB.

Steps to reproduce

Run Hoppscotch from Docker AIO container connected to a PSQL database like described in https://docs.hoppscotch.io/documentation/self-host/community-edition/install-and-build
Login
Go to GraphQL tab
Create a Collection
Create a request in that collection
Execute it and hit "Save":
Looking into the database in table UserRequest we see that the attributes in request are not matching the request saved in the UI:

Could it be that I need to change sth within my configuration? This is how .env is looking like:


#-----------------------Backend Config------------------------------#
# Prisma Config
DATABASE_URL=postgresql://<dbuser>:<dbpasswd>@<dbip>5432/hoppscotch_db

# Auth Tokens Config
JWT_SECRET=...
TOKEN_SALT_COMPLEXITY=22
# Duration of the validity of the magic link being sent to sign in to Hoppscotch (in days).
MAGIC_LINK_TOKEN_VALIDITY=1
# Default validity is 7 days (604800000 ms) in ms
REFRESH_TOKEN_VALIDITY=604800000
# Default validity is 1 day (86400000 ms) in ms
ACCESS_TOKEN_VALIDITY=86400000
SESSION_SECRET=...

# Recommended to be true. Set to false if you are using http.
# Note: Some auth providers may not support http requests and may stop working when set to false.
ALLOW_SECURE_COOKIES=true

# Sensitive Data Encryption Key while storing in Database (32 character)
DATA_ENCRYPTION_KEY=...

# Hoppscotch App Domain Config
REDIRECT_URL=http://localhost:3000
WHITELISTED_ORIGINS=http://localhost:3170,http://localhost:3000,http://localhost:3100
VITE_ALLOWED_AUTH_PROVIDERS=GOOGLE

# Google Auth Config
GOOGLE_CLIENT_ID=...
GOOGLE_CLIENT_SECRET=....
GOOGLE_CALLBACK_URL=http://localhost:3170/v1/auth/google/callback
GOOGLE_SCOPE=email,profile

# Mailer config
MAILER_SMTP_ENABLE=true
MAILER_USE_CUSTOM_CONFIGS=true
MAILER_ADDRESS_FROM=...
# The following are used if custom mailer configs is true
MAILER_SMTP_HOST=....
MAILER_SMTP_PORT=587
MAILER_SMTP_SECURE=true
MAILER_SMTP_USER=...
MAILER_SMTP_PASSWORD=...
MAILER_TLS_REJECT_UNAUTHORIZED=true

# Rate Limit Config
# In seconds
RATE_LIMIT_TTL=60
# Max requests per IP
RATE_LIMIT_MAX=80

#-----------------------Frontend Config------------------------------#

# Base URLs
VITE_BASE_URL=http://localhost:3000
VITE_SHORTCODE_BASE_URL=http://localhost:3000
VITE_ADMIN_URL=http://localhost:3100

# Backend URLs
VITE_BACKEND_GQL_URL=http://localhost:3170/graphql
VITE_BACKEND_WS_URL=wss://localhost:3170/graphql
VITE_BACKEND_API_URL=http://localhost:3170/v1

# Terms Of Service And Privacy Policy Links (Optional)
VITE_APP_TOS_LINK=https://docs.hoppscotch.io/support/terms
VITE_APP_PRIVACY_POLICY_LINK=https://docs.hoppscotch.io/support/privacy

# Set to `true` for subpath based access
ENABLE_SUBPATH_BASED_ACCESS=false

Environment

Production

Version

Self-hosted

Originally created by @rb090 on GitHub (Oct 30, 2024). Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/4500 ### Is there an existing issue for this? - [X] I have searched the existing issues ### Current behavior When I create a new GraphQL request within a Hoppscotch GraphQL request collection, its content gets not saved properly to the connected database to `UserRequest.request` into the properties `query` and `variables`. I am running Hoppscotch Community Edition via Docker AIO container on version `v2024.9.3`. It is connected to a PSQL DB. ### Steps to reproduce 1. Run Hoppscotch from Docker AIO container connected to a PSQL database like described in https://docs.hoppscotch.io/documentation/self-host/community-edition/install-and-build 2. Login 3. Go to GraphQL tab 4. Create a [Collection](https://docs.hoppscotch.io/documentation/features/collections) 5. Create a request in that collection 6. Execute it and hit "Save": ![Bildschirmfoto 2024-10-30 um 17 45 00](https://github.com/user-attachments/assets/5b40c67f-a0a8-4755-b6bf-14a5aaf71124) 7. Looking into the database in table `UserRequest` we see that the attributes in `request` are not matching the request saved in the UI: <img width="925" alt="Bildschirmfoto 2024-10-30 um 22 12 23" src="https://github.com/user-attachments/assets/9e0c4aa0-be1f-484a-82d8-05313778d5c6"> Could it be that I need to change sth within my configuration? This is how `.env` is looking like: ``` #-----------------------Backend Config------------------------------# # Prisma Config DATABASE_URL=postgresql://<dbuser>:<dbpasswd>@<dbip>5432/hoppscotch_db # Auth Tokens Config JWT_SECRET=... TOKEN_SALT_COMPLEXITY=22 # Duration of the validity of the magic link being sent to sign in to Hoppscotch (in days). MAGIC_LINK_TOKEN_VALIDITY=1 # Default validity is 7 days (604800000 ms) in ms REFRESH_TOKEN_VALIDITY=604800000 # Default validity is 1 day (86400000 ms) in ms ACCESS_TOKEN_VALIDITY=86400000 SESSION_SECRET=... # Recommended to be true. Set to false if you are using http. # Note: Some auth providers may not support http requests and may stop working when set to false. ALLOW_SECURE_COOKIES=true # Sensitive Data Encryption Key while storing in Database (32 character) DATA_ENCRYPTION_KEY=... # Hoppscotch App Domain Config REDIRECT_URL=http://localhost:3000 WHITELISTED_ORIGINS=http://localhost:3170,http://localhost:3000,http://localhost:3100 VITE_ALLOWED_AUTH_PROVIDERS=GOOGLE # Google Auth Config GOOGLE_CLIENT_ID=... GOOGLE_CLIENT_SECRET=.... GOOGLE_CALLBACK_URL=http://localhost:3170/v1/auth/google/callback GOOGLE_SCOPE=email,profile # Mailer config MAILER_SMTP_ENABLE=true MAILER_USE_CUSTOM_CONFIGS=true MAILER_ADDRESS_FROM=... # The following are used if custom mailer configs is true MAILER_SMTP_HOST=.... MAILER_SMTP_PORT=587 MAILER_SMTP_SECURE=true MAILER_SMTP_USER=... MAILER_SMTP_PASSWORD=... MAILER_TLS_REJECT_UNAUTHORIZED=true # Rate Limit Config # In seconds RATE_LIMIT_TTL=60 # Max requests per IP RATE_LIMIT_MAX=80 #-----------------------Frontend Config------------------------------# # Base URLs VITE_BASE_URL=http://localhost:3000 VITE_SHORTCODE_BASE_URL=http://localhost:3000 VITE_ADMIN_URL=http://localhost:3100 # Backend URLs VITE_BACKEND_GQL_URL=http://localhost:3170/graphql VITE_BACKEND_WS_URL=wss://localhost:3170/graphql VITE_BACKEND_API_URL=http://localhost:3170/v1 # Terms Of Service And Privacy Policy Links (Optional) VITE_APP_TOS_LINK=https://docs.hoppscotch.io/support/terms VITE_APP_PRIVACY_POLICY_LINK=https://docs.hoppscotch.io/support/privacy # Set to `true` for subpath based access ENABLE_SUBPATH_BASED_ACCESS=false ``` ### Environment Production ### Version Self-hosted

kerem

2026-03-16 21:13:32 +03:00

closed this issue
added the
bug

need testing
labels

kerem commented

2026-03-16 21:13:48 +03:00

Author

Owner

@AndrewBastin commented on GitHub (Nov 13, 2024):

Should be fixed as of 2024.10.2

@AndrewBastin commented on GitHub (Nov 13, 2024): Should be fixed as of 2024.10.2

kerem commented

2026-03-16 21:13:53 +03:00

Author

Owner

@jamesgeorge007 commented on GitHub (Nov 14, 2024):

Create a Collection
Create a request in that collection
Execute it and hit "Save":

Hi @rb090, while you add a request, could you check if clicking on the request from the collection tree for the second time opens a new tab with the association being kept (any further updates are recorded correctly)? You can find a pill next to the request in the tree when it's open in a tab indicating it's the active item. Observe the association wasn't kept when the tab was open with the request being created, but during the second attempt, it would be marked as an active entry.

We were able to reproduce issues with requests from the GraphQL collection tree and the tab getting dissociated following certain actions that can lead to a flow where the updates to the original request are lost and a fix is up for the same.

@jamesgeorge007 commented on GitHub (Nov 14, 2024): > Create a [Collection](https://docs.hoppscotch.io/documentation/features/collections) Create a request in that collection Execute it and hit "Save": Hi @rb090, while you add a request, could you check if clicking on the request from the collection tree for the second time opens a new tab with the association being kept (any further updates are recorded correctly)? You can find a pill next to the request in the tree when it's open in a tab indicating it's the active item. Observe the association wasn't kept when the tab was open with the request being created, but during the second attempt, it would be marked as an active entry. ![image](https://github.com/user-attachments/assets/c1fe2795-e22f-45d7-b28f-f5db6f4a3a7e) We were able to reproduce issues with requests from the GraphQL collection tree and the tab getting dissociated following certain actions that can lead to a flow where the updates to the original request are lost and a [fix]([url](https://github.com/hoppscotch/hoppscotch/pull/4537)) is up for the same.

kerem commented

2026-03-16 21:13:58 +03:00

Author

Owner

@rb090 commented on GitHub (Nov 14, 2024):

Hi @jamesgeorge007,

I am sorry for the late reply. Thank you so much that you are looking into this issue. We really appreciate this a lot.

could you check if clicking on the request from the collection tree for the second time opens a new tab with the association being kept

No it does not. Lets say I have a request "TestQuery". If "TestQuery" is open in a tab and I click again on the request item in the collection, that does not happen.

If no query "TestQuery" is open in a tab, I click on it in the collection once I created it, tab is opened and the green dot appers.

Updates on the request are saved until I do a reload in my browser 😔.

Observe the association wasn't kept when the tab was open with the request being created, but during the second attempt, it would be marked as an active entry.

Good catch, you are right on this.

@rb090 commented on GitHub (Nov 14, 2024): Hi @jamesgeorge007, I am sorry for the late reply. Thank you so much that you are looking into this issue. We really appreciate this a lot. > could you check if clicking on the request from the collection tree for the second time opens a new tab with the association being kept No it does not. Lets say I have a request "TestQuery". If "TestQuery" is open in a tab and I click again on the request item in the collection, that does not happen. If no query "TestQuery" is open in a tab, I click on it in the collection once I created it, tab is opened and the green dot appers. Updates on the request are saved until I do a reload in my browser 😔. > Observe the association wasn't kept when the tab was open with the request being created, but during the second attempt, it would be marked as an active entry. Good catch, you are right on this.

kerem commented

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

Author

Owner

@jamesgeorge007 commented on GitHub (Nov 15, 2024):

could you check if clicking on the request from the collection tree for the second time opens a new tab with the association being kept

No it does not. Lets say I have a request "TestQuery". If "TestQuery" is open in a tab and I click again on the request item in the collection, that does not happen.

In this case, was the request open in a tab following the create action with no active indicator next to the request from the collection tree? Could you send a screen recording of this flow here or via the existing communication channel with @AndrewBastin as you prefer with any sensitive contents redacted?

Also, if possible, at this stage, could you send the contents against the keys collectionsGraphql and gqlTabState from localStorage (sensitive contents redacted) that might help with reproducing on our end? Based on the investigation so far, the underlying issue occurs when the request open under the tab following the create action is not the original request from the collection tree.

@jamesgeorge007 commented on GitHub (Nov 15, 2024): > could you check if clicking on the request from the collection tree for the second time opens a new tab with the association being kept > > No it does not. Lets say I have a request "TestQuery". If "TestQuery" is open in a tab and I click again on the request item in the collection, that does not happen. In this case, was the request open in a tab following the create action with no active indicator next to the request from the collection tree? Could you send a screen recording of this flow here or via the existing communication channel with @AndrewBastin as you prefer with any sensitive contents redacted? Also, if possible, at this stage, could you send the contents against the keys `collectionsGraphql` and `gqlTabState` from `localStorage` (sensitive contents redacted) that might help with reproducing on our end? Based on the investigation so far, the underlying issue occurs when the request open under the tab following the create action is not the original request from the collection tree.

kerem commented

2026-03-16 21:14:08 +03:00

Author

Owner

@rb090 commented on GitHub (Nov 15, 2024):

@jamesgeorge007 what do you think in having a call where we can debug and have a look together? I have the feeling that might be easier. If you agree please share with me how you are available and I can setup us sth.

@rb090 commented on GitHub (Nov 15, 2024): @jamesgeorge007 what do you think in having a call where we can debug and have a look together? I have the feeling that might be easier. If you agree please share with me how you are available and I can setup us sth.

kerem commented

2026-03-16 21:14:13 +03:00

Author

Owner

@jamesgeorge007 commented on GitHub (Nov 18, 2024):

I had a chat with @AndrewBastin. Since there is already a fix addressing the concern about requests not getting synced to the workspace arising from the collection tree and tab state dissociating, let's schedule a call after the release as required if there are further concerns :)

@jamesgeorge007 commented on GitHub (Nov 18, 2024): I had a chat with @AndrewBastin. Since there is already a fix addressing the concern about requests not getting synced to the workspace arising from the collection tree and tab state dissociating, let's schedule a call after the release as required if there are further concerns :)

kerem commented

2026-03-16 21:14:19 +03:00

Author

Owner

@rb090 commented on GitHub (Nov 18, 2024):

Thanks a lot for getting back to me @jamesgeorge007 and for working on this fix with @AndrewBastin 🙌💗. So we wait for the next release v2024.10.3? And once the new release is out I would then test again and get back to you.

@rb090 commented on GitHub (Nov 18, 2024): Thanks a lot for getting back to me @jamesgeorge007 and for working on this fix with @AndrewBastin 🙌💗. So we wait for the next release `v2024.10.3`? And once the new release is out I would then test again and get back to you.

kerem commented

2026-03-16 21:14:24 +03:00

Author

Owner

@jamesgeorge007 commented on GitHub (Nov 20, 2024):

A quick update regarding a change in the release plan. The v2024.11.0 major release is scheduled for next week and the above fix will be part of the same.

@jamesgeorge007 commented on GitHub (Nov 20, 2024): A quick update regarding a change in the release plan. The `v2024.11.0` major release is scheduled for next week and the above fix will be part of the same.

kerem commented

2026-03-16 21:14:29 +03:00

Author

Owner

@rb090 commented on GitHub (Nov 20, 2024):

@jamesgeorge007 oh wow that are awesome news, thank you so much for your update on this and for taking care of this issue 🙌🍾. Looking forward to it. I will test with the new release and let you know in this ticket how it goes.

@rb090 commented on GitHub (Nov 20, 2024): @jamesgeorge007 oh wow that are awesome news, thank you so much for your update on this and for taking care of this issue 🙌🍾. Looking forward to it. I will test with the new release and let you know in this ticket how it goes.

kerem commented

2026-03-16 21:14:34 +03:00

Author

Owner

@jamesgeorge007 commented on GitHub (Nov 28, 2024):

Hi, the above fix is now released in v2024.11.0. Please let us know if the issue persists.
Ensure to close the active tabs and start afresh.

@jamesgeorge007 commented on GitHub (Nov 28, 2024): Hi, the above fix is now released in [v2024.11.0](https://github.com/hoppscotch/hoppscotch/releases/tag/2024.11.0). Please let us know if the issue persists. Ensure to close the active tabs and start afresh.

kerem commented

2026-03-16 21:14:39 +03:00

Author

Owner

@rb090 commented on GitHub (Dec 2, 2024):

Hi @jamesgeorge007,

Thank you so much for the update and the fix 🙌! I hope you don’t mind the delay in my response, I was out of the office. I had the chance to test your fix today.

It seems that adding GraphQL requests initially works perfectly, and all requests are added correctly with their content. However, once a request is saved, it’s not possible to make changes to it. Modifications to existing GraphQL requests aren’t being applied. When I check the database, the changes aren’t reflected there either.

Could you please also let me know how to share GraphQL requests with teammates? For example, GraphQL requests I created aren't visible to any of my colleagues. Do workspaces not support sharing GraphQL requests?

@rb090 commented on GitHub (Dec 2, 2024): Hi @jamesgeorge007, Thank you so much for the update and the fix 🙌! I hope you don’t mind the delay in my response, I was out of the office. I had the chance to test your fix today. It seems that adding GraphQL requests initially works perfectly, and all requests are added correctly with their content. However, once a request is saved, it’s not possible to make changes to it. Modifications to existing GraphQL requests aren’t being applied. When I check the database, the changes aren’t reflected there either. Could you please also let me know how to share GraphQL requests with teammates? For example, GraphQL requests I created aren't visible to any of my colleagues. Do workspaces not support sharing GraphQL requests?

kerem commented

2026-03-16 21:14:44 +03:00

Author

Owner

@jamesgeorge007 commented on GitHub (Dec 2, 2024):

No worries, thanks for getting back.

It seems that adding GraphQL requests initially works perfectly, and all requests are added correctly with their content. However, once a request is saved, it’s not possible to make changes to it. Modifications to existing GraphQL requests aren’t being applied. When I check the database, the changes aren’t reflected there either.

Could you post a screen recording of the flow?

Could you please also let me know how to share GraphQL requests with teammates? For example, GraphQL requests I created aren't visible to any of my colleagues. Do workspaces not support sharing GraphQL requests?

So currently, GraphQL applies only to the personal workspace, ref.

@jamesgeorge007 commented on GitHub (Dec 2, 2024): No worries, thanks for getting back. > It seems that adding GraphQL requests initially works perfectly, and all requests are added correctly with their content. However, once a request is saved, it’s not possible to make changes to it. Modifications to existing GraphQL requests aren’t being applied. When I check the database, the changes aren’t reflected there either. Could you post a screen recording of the flow? > Could you please also let me know how to share GraphQL requests with teammates? For example, GraphQL requests I created aren't visible to any of my colleagues. Do workspaces not support sharing GraphQL requests? So currently, GraphQL applies only to the personal workspace, [ref](https://docs.hoppscotch.io/documentation/features/workspaces).

kerem commented

2026-03-16 21:14:49 +03:00

Author

Owner

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

Thank you so much for getting back to me @jamesgeorge007 and for providing the clarifications! I really appreciate your prompt response 🙌.

So currently, GraphQL applies only to the personal workspace, ref.

I understand that GraphQL is currently limited to personal workspaces. But it would be incredibly helpful for our team if we could share these across our workspace. Is there any chance this feature could be introduced soon? Are there any plans?

Additionally, I recorded a quick screencast to demonstrate an issue I encountered. In the video, I open an existing request, make some changes, and then open a new tab to re-open the modified request. However, as shown, the attributes I removed still appear. I hope the video provides clarity, but I'm happy to jump on a call if further discussion is needed 🙂.

https://github.com/user-attachments/assets/ad58db99-f834-4fe3-a665-65a6f89bd618

@rb090 commented on GitHub (Dec 3, 2024): Thank you so much for getting back to me @jamesgeorge007 and for providing the clarifications! I really appreciate your prompt response 🙌. > So currently, GraphQL applies only to the personal workspace, [ref](https://docs.hoppscotch.io/documentation/features/workspaces). I understand that GraphQL is currently limited to personal workspaces. But it would be incredibly helpful for our team if we could share these across our workspace. Is there any chance this feature could be introduced soon? Are there any plans? Additionally, I recorded a quick screencast to demonstrate an issue I encountered. In the video, I open an existing request, make some changes, and then open a new tab to re-open the modified request. However, as shown, the attributes I removed still appear. I hope the video provides clarity, but I'm happy to jump on a call if further discussion is needed 🙂. https://github.com/user-attachments/assets/ad58db99-f834-4fe3-a665-65a6f89bd618

kerem commented

2026-03-16 21:14:54 +03:00

Author

Owner

@jamesgeorge007 commented on GitHub (Dec 3, 2024):

So currently, GraphQL applies only to the personal workspace, ref.

I understand that GraphQL is currently limited to personal workspaces. But it would be incredibly helpful for our team if we could share these across our workspace. Is there any chance this feature could be introduced soon? Are there any plans?

There are no immediate plans but, we have it in the pipeline. You can keep an eye on the open issues :)

Additionally, I recorded a quick screencast to demonstrate an issue I encountered. In the video, I open an existing request, make some changes, and then open a new tab to re-open the modified request. However, as shown, the attributes I removed still appear. I hope the video provides clarity, but I'm happy to jump on a call if further discussion is needed 🙂.

Thanks. We'll investigate further.

@jamesgeorge007 commented on GitHub (Dec 3, 2024): > So currently, GraphQL applies only to the personal workspace, [ref](https://docs.hoppscotch.io/documentation/features/workspaces). > > I understand that GraphQL is currently limited to personal workspaces. But it would be incredibly helpful for our team if we could share these across our workspace. Is there any chance this feature could be introduced soon? Are there any plans? There are no immediate plans but, we have it in the pipeline. You can keep an eye on the open issues :) > Additionally, I recorded a quick screencast to demonstrate an issue I encountered. In the video, I open an existing request, make some changes, and then open a new tab to re-open the modified request. However, as shown, the attributes I removed still appear. I hope the video provides clarity, but I'm happy to jump on a call if further discussion is needed 🙂. Thanks. We'll investigate further.

kerem commented

2026-03-16 21:14:59 +03:00

Author

Owner

@jamesgeorge007 commented on GitHub (Dec 23, 2024):

Hi, we have a patch that went out with the v2024.12.0 release, which addresses issues with request syncing. Could you take a look when you get a chance?

@jamesgeorge007 commented on GitHub (Dec 23, 2024): Hi, we have a [patch](https://github.com/hoppscotch/hoppscotch/pull/4587) that went out with the [v2024.12.0](https://github.com/hoppscotch/hoppscotch/releases/tag/2024.12.0) release, which addresses issues with request syncing. Could you take a look when you get a chance?

kerem commented

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

Author

Owner

@rb090 commented on GitHub (Dec 29, 2024):

Thank you so much, @jamesgeorge007, for letting me know and for providing the patch! I tested the new version today, and everything looks great so far. I modified existing requests, deleted collections with requests, and created new collections with requests. Everything seems to be working perfectly from what I can see.

Thank you again for addressing these issues. Wishing you and the entire team a happy and healthy New Year! 🎉🎆

@rb090 commented on GitHub (Dec 29, 2024): Thank you so much, @jamesgeorge007, for letting me know and for providing the patch! I tested the new version today, and everything looks great so far. I modified existing requests, deleted collections with requests, and created new collections with requests. Everything seems to be working perfectly from what I can see. Thank you again for addressing these issues. Wishing you and the entire team a happy and healthy New Year! 🎉🎆

kerem commented

2026-03-16 21:15:10 +03:00

Author

Owner

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

Awesome, thanks for confirming; closing this issue. Happy New Year 🥳

@jamesgeorge007 commented on GitHub (Jan 1, 2025): Awesome, thanks for confirming; closing this issue. Happy New Year 🥳

kerem referenced this issue

2026-03-17 01:03:26 +03:00

[PR #1643] [CLOSED] Removed Redundant code in nuxt.config.js #3444

Rows
Columns

[GH-ISSUE #4500] [bug]: GraphQL Requests not saved to DB #1643

Is there an existing issue for this?

Current behavior

Steps to reproduce

Environment

Version