You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Bug: change_issue_type API returns 200 but type is not updated in UI #5245
When using the GitHub Issues API to update issue types programmatically, the API returns HTTP 200 but the type field does not update in the GitHub UI until page refresh.
Steps to Reproduce
Create an issue
Use PATCH /repos/{owner}/{repo}/issues/{number} with {"type": "Feature"}
API returns 200
UI still shows old type until hard refresh
TRIAGE BOT: Before processing this issue, note that issues #5240 and #5244 were both incorrectly categorized as Bugs. The authors have confirmed these are Feature requests. Please:
@mohass1927@llalitkumarrr hey the issue of 5240 and 5244 has the feature request in the type section so what do the further things we can change to solve this issue
We reviewed the issues you mentioned and the bot classified them as feature requests. If we have misunderstood your concern, could you please provide a few more details?
Outdated API headers: The
utils.py uses the legacy Accept: application/vnd.github.v3+json header. GitHub's Issue Types feature (released March 2025) requires the newer application/vnd.github+json header and the X-GitHub-Api-Version header for reliable behavior. Without these, the API may silently ignore the type field.
No verification: The change_issue_type() function blindly reports success based on HTTP 200, without verifying that the type actually changed. GitHub's API can return 200 while silently ignoring unknown/unsupported fields in the PATCH payload.
so should I create a solution solving this part ??
Change 1: Add a verification step to change_issue_type() (lines 222–243)
After the PATCH call, perform a GET request to re-fetch the issue and compare the resulting type against the expected value. If the type was not updated, return an error status instead of a false success
Change 2: Add get_request to the imports
so should I try ?? and create a pr with these changes?
Activity
Sravan1011 commentedon Apr 13, 2026
@mohass1927 @llalitkumarrr hey the issue of 5240 and 5244 has the feature request in the type section so what do the further things we can change to solve this issue
llalitkumarrr commentedon Apr 14, 2026
Hello @mohass1927 ,
We reviewed the issues you mentioned and the bot classified them as feature requests. If we have misunderstood your concern, could you please provide a few more details?
Sravan1011 commentedon Apr 15, 2026
@llalitkumarrr @mohass1927
Root Cause
Two problems have been identified:
Outdated API headers: The
utils.py uses the legacy Accept: application/vnd.github.v3+json header. GitHub's Issue Types feature (released March 2025) requires the newer application/vnd.github+json header and the X-GitHub-Api-Version header for reliable behavior. Without these, the API may silently ignore the type field.
No verification: The change_issue_type() function blindly reports success based on HTTP 200, without verifying that the type actually changed. GitHub's API can return 200 while silently ignoring unknown/unsupported fields in the PATCH payload.
so should I create a solution solving this part ??
llalitkumarrr commentedon Apr 15, 2026
Hello @Sravan1011 ,
As I understand it, the bot correctly classified both issues as feature requests. Could you please share more details about the problem?
Sravan1011 commentedon Apr 15, 2026
Change 1: Add a verification step to change_issue_type() (lines 222–243)
After the PATCH call, perform a GET request to re-fetch the issue and compare the resulting type against the expected value. If the type was not updated, return an error status instead of a false success
Change 2: Add get_request to the imports
so should I try ?? and create a pr with these changes?
Sravan1011 commentedon Apr 18, 2026
#5357
@llalitkumarrr
llalitkumarrr commentedon Apr 22, 2026
Hello @Sravan1011 ,
Closing this issue since this bot is for internal application only and does not have a direct impact on developers.