[Bug][github_graphql] enableGraphql resets to false despite no value sent in GitHub connection update

[Adisorn-Watt]

Search before asking

• I had searched in the issues and found no similar issues.

What happened

When editing a GitHub connection that enableGraphql = true via the config UI, and saving the changes (such as updating the token). Even though the config UI does not send any of enableGraphql value via the payload, the PATCH API response returns enableGraphql as false. Resulting in the inability to sync GitHub workflow/deployments data which is only available via GitHub Graphql plugin.

What do you expect to happen

The enableGraphql value should remain its original value (true) after editing and saving the connection. It should not automatically change to false.

How to reproduce

1. Select any GitHub connection with enableGraphql = true (verify via inspect GET connections API).
2. Edit the connection (e.g., change the token).
3. Save the changes.
4. Observe that the PATCH API response returns enableGraphql as false.

Anything else

No additional information

Version

v1.0.1

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

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

[dosubot]

Hey @Adisorn-Watt! I'm here to help you with any bugs, questions, or contributions you have in mind. Let's tackle this together!

The enableGraphql field resets to false in the PATCH API response because fine-grained personal access tokens do not support GraphQL APIs. The documentation specifies that you must disable Use GraphQL APIs on the connection page if you are using a fine-grained personal access token. This requirement likely causes the system to automatically reset enableGraphql to false when such a token is detected, even if no value for enableGraphql is sent in the request. Additionally, using fine-grained PATs without GraphQL will significantly increase the data collection time, which is an important consideration when configuring your connection ^[1][2].

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other}

[Adisorn-Watt]

Hey @dosu, thanks for the answer. However, we are using Classic personal access tokens, therefore I don't think your answer can be applied to our situation.

[dosubot]

The behavior you're experiencing with the enableGraphql field resetting to false despite using Classic personal access tokens is not directly addressed in the available documentation. It's possible that there might be a logic in the codebase that defaults the enableGraphql field to false under certain conditions, even when using Classic tokens. Unfortunately, I couldn't find specific details about this logic or any related issues in the repository. You might want to check the code handling the PATCH API request to see if there are any conditions or defaults affecting the enableGraphql field.

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other}

[klesh]

Thanks for reporting the issue, will look into it soon

[kostas-petrakis]

Coming here as it seems on the 1.0.2-beta4 the GraphQL option is completely gone from the UI, I can see the enable_graphql column in the DB set to 0

Screenshot from the popup adding a new GitHub connection (same applies for my existing connection)

[klesh]

Coming here as it seems on the 1.0.2-beta4 the GraphQL option is completely gone from the UI, I can see the enable_graphql column in the DB set to 0

Screenshot from the popup adding a new GitHub connection (same applies for my existing connection)

Yes, it is intended. GraphQL option can not be disabled since then.

[kostas-petrakis]

@klesh shouldn't then be enabled within the DB by default? enable_graphql is set to 0 in our DB

[klesh]

@klesh shouldn't then be enabled within the DB by default? enable_graphql is set to 0 in our DB

Good point, I agree.
Maybe one step further? Like getting rid of the option altogether.
Would you like to work on it?

[kostas-petrakis]

@klesh I will try to pick this up, will create a separate issue. 👍