Summary

Add connected service account "needs attention" and track GH App state.

Review Request #15197 — Created July 24, 2026 and updated July 24, 2026, 4:02 p.m.

Information

Owner

david

Repository

Review Board

Branch

release-9.x

Bugs

Depends On

Reviewers

Groups

reviewboard

People

Description

GitHub Apps can be uninstalled or suspended from the GitHub side, which
can cause our integration to start failing. This change makes us handle
that in a nice way. This involves several pieces:

Connected Services "needs attention"

Accounts can now indicate that they need attention in some way, and
provide actions to handle this.

This is now implemented for app-based accounts with GitHub in order to
allow the admin to reestablish the correction.

Later work will involve using this for other hosting services (and
PAT-based GitHub connections) to have accounts indicate when their
credentials need to be updated.

GitHub App webhook handler

The stub webhook handler has been fleshed out to verify the signature
header and handle several events:

deleted and suspend mark the installation account with the state
so that they'll be flagged in the connected services list.
created can heal a reinstall by refreshing the stored installation
ID, matched to the existing account. This allows a reinstall performed
entirely from the GitHub side to restore the connection without
requiring anything to happen inside Review Board.
installation_repositories keeps the repository_selection flag up
to date.
installation_target updates the stored account name.

API request error handling

In the case of a missed webhook delivery, we can still end up with the
stored state being wrong (in either direction). API requests have been
updated to handle this in two ways:

Token minting will map a 403 or 404 response to the
suspended/uninstalled state (checking first to ensure that it's not
some other ephemeral failure or rate limit error). If we got the error
because the app had been uninstalled but is now reinstalled, we'll
adopt the new installation ID.
403 or 404 errors for cached installation tokens will drop the token
and try again (limited to once per minute).
If we have a stored non-active status, we'll recheck that state (also
limited to once per minute) before refusing to mint a new token.

GitHub reconnect

The reconnect action for suspended/uninstalled accounts will first try
to verify that state (in case of a missed webhook delivery), and if it's
still an issue, will deep link the user to the relevant page where they
can fix it.

Testing Done


Ran unit tests.
Suspended and deleted app installs and saw that the state was properly

  reflected in the connected services list.
Reconnected suspended and deleted app installs and saw that state

  healed correctly.

Commits

Summary	ID
Add connected service account "needs attention" and track GH App state. GitHub Apps can be uninstalled or suspended from the GitHub side, which can cause our integration to start failing. This change makes us handle that in a nice way. This involves several pieces: # Connected Services "needs attention" Accounts can now indicate that they need attention in some way, and provide actions to handle this. This is now implemented for app-based accounts with GitHub in order to allow the admin to reestablish the correction. Later work will involve using this for other hosting services (and PAT-based GitHub connections) to have accounts indicate when their credentials need to be updated. # GitHub App webhook handler The stub webhook handler has been fleshed out to verify the signature header and handle several events: - `deleted` and `suspend` mark the installation account with the state so that they'll be flagged in the connected services list. - `created` can heal a reinstall by refreshing the stored installation ID, matched to the existing account. This allows a reinstall performed entirely from the GitHub side to restore the connection without requiring anything to happen inside Review Board. - `installation_repositories` keeps the `repository_selection` flag up to date. - `installation_target` updates the stored account name. # API request error handling In the case of a missed webhook delivery, we can still end up with the stored state being wrong (in either direction). API requests have been updated to handle this in two ways: - Token minting will map a 403 or 404 response to the suspended/uninstalled state (checking first to ensure that it's not some other ephemeral failure or rate limit error). If we got the error because the app had been uninstalled but is now reinstalled, we'll adopt the new installation ID. - 403 or 404 errors for cached installation tokens will drop the token and try again (limited to once per minute). - If we have a stored non-active status, we'll recheck that state (also limited to once per minute) before refusing to mint a new token. # GitHub reconnect The reconnect action for suspended/uninstalled accounts will first try to verify that state (in case of a missed webhook delivery), and if it's still an issue, will deep link the user to the relevant page where they can fix it. Testing Done: - Ran unit tests. - Suspended and deleted app installs and saw that the state was properly reflected in the connected services list. - Reconnected suspended and deleted app installs and saw that state healed correctly.	ummslvyqxyoqyzlozxkmksvtrxvnrpwn

Summary

Add connected service account "needs attention" and track GH App state.

GitHub Apps can be uninstalled or suspended from the GitHub side, which can cause our integration to start failing. This change makes us handle that in a nice way. This involves several pieces: # Connected Services "needs attention" Accounts can now indicate that they need attention in some way, and provide actions to handle this. This is now implemented for app-based accounts with GitHub in order to allow the admin to reestablish the correction. Later work will involve using this for other hosting services (and PAT-based GitHub connections) to have accounts indicate when their credentials need to be updated. # GitHub App webhook handler The stub webhook handler has been fleshed out to verify the signature header and handle several events: - `deleted` and `suspend` mark the installation account with the state so that they'll be flagged in the connected services list. - `created` can heal a reinstall by refreshing the stored installation ID, matched to the existing account. This allows a reinstall performed entirely from the GitHub side to restore the connection without requiring anything to happen inside Review Board. - `installation_repositories` keeps the `repository_selection` flag up to date. - `installation_target` updates the stored account name. # API request error handling In the case of a missed webhook delivery, we can still end up with the stored state being wrong (in either direction). API requests have been updated to handle this in two ways: - Token minting will map a 403 or 404 response to the suspended/uninstalled state (checking first to ensure that it's not some other ephemeral failure or rate limit error). If we got the error because the app had been uninstalled but is now reinstalled, we'll adopt the new installation ID. - 403 or 404 errors for cached installation tokens will drop the token and try again (limited to once per minute). - If we have a stored non-active status, we'll recheck that state (also limited to once per minute) before refusing to mint a new token. # GitHub reconnect The reconnect action for suspended/uninstalled accounts will first try to verify that state (in case of a missed webhook delivery), and if it's still an issue, will deep link the user to the relevant page where they can fix it. Testing Done: - Ran unit tests. - Suspended and deleted app installs and saw that the state was properly reflected in the connected services list. - Reconnected suspended and deleted app installs and saw that state healed correctly.

ummslvyqxyoqyzlozxkmksvtrxvnrpwn

Files

Issues

Description	From	Last Updated
line too long (80 > 79 characters) Column: 80 Error code: E501	reviewbot	July 24, 2026, 4:02 p.m.
line too long (83 > 79 characters) Column: 80 Error code: E501	reviewbot	July 24, 2026, 4:02 p.m.

flake8 failed.

JSHint passed.

flake8

reviewboard/admin/views.py (Diff revision 1)
The issue has been dropped. Show all issues
```
line too long (80 > 79 characters)

Column: 80
Error code: E501
```
reviewboard/admin/views.py (Diff revision 1)
The issue has been dropped. Show all issues
```
line too long (83 > 79 characters)

Column: 80
Error code: E501
```

Commits:

	Summary	ID
	Add connected service account "needs attention" and track GH App state. GitHub Apps can be uninstalled or suspended from the GitHub side, which can cause our integration to start failing. This change makes us handle that in a nice way. This involves several pieces: # Connected Services "needs attention" Accounts can now indicate that they need attention in some way, and provide actions to handle this. This is now implemented for app-based accounts with GitHub in order to allow the admin to reestablish the correction. Later work will involve using this for other hosting services (and PAT-based GitHub connections) to have accounts indicate when their credentials need to be updated. # GitHub App webhook handler The stub webhook handler has been fleshed out to verify the signature header and handle several events: - `deleted` and `suspend` mark the installation account with the state so that they'll be flagged in the connected services list. - `created` can heal a reinstall by refreshing the stored installation ID, matched to the existing account. This allows a reinstall performed entirely from the GitHub side to restore the connection without requiring anything to happen inside Review Board. - `installation_repositories` keeps the `repository_selection` flag up to date. - `installation_target` updates the stored account name. # API request error handling In the case of a missed webhook delivery, we can still end up with the stored state being wrong (in either direction). API requests have been updated to handle this in two ways: - Token minting will map a 403 or 404 response to the suspended/uninstalled state (checking first to ensure that it's not some other ephemeral failure or rate limit error). If we got the error because the app had been uninstalled but is now reinstalled, we'll adopt the new installation ID. - 403 or 404 errors for cached installation tokens will drop the token and try again (limited to once per minute). - If we have a stored non-active status, we'll recheck that state (also limited to once per minute) before refusing to mint a new token. # GitHub reconnect The reconnect action for suspended/uninstalled accounts will first try to verify that state (in case of a missed webhook delivery), and if it's still an issue, will deep link the user to the relevant page where they can fix it. Testing Done: - Ran unit tests. - Suspended and deleted app installs and saw that the state was properly reflected in the connected services list. - Reconnected suspended and deleted app installs and saw that state healed correctly.	ummslvyqxyoqyzlozxkmksvtrxvnrpwn
	Add connected service account "needs attention" and track GH App state. GitHub Apps can be uninstalled or suspended from the GitHub side, which can cause our integration to start failing. This change makes us handle that in a nice way. This involves several pieces: # Connected Services "needs attention" Accounts can now indicate that they need attention in some way, and provide actions to handle this. This is now implemented for app-based accounts with GitHub in order to allow the admin to reestablish the correction. Later work will involve using this for other hosting services (and PAT-based GitHub connections) to have accounts indicate when their credentials need to be updated. # GitHub App webhook handler The stub webhook handler has been fleshed out to verify the signature header and handle several events: - `deleted` and `suspend` mark the installation account with the state so that they'll be flagged in the connected services list. - `created` can heal a reinstall by refreshing the stored installation ID, matched to the existing account. This allows a reinstall performed entirely from the GitHub side to restore the connection without requiring anything to happen inside Review Board. - `installation_repositories` keeps the `repository_selection` flag up to date. - `installation_target` updates the stored account name. # API request error handling In the case of a missed webhook delivery, we can still end up with the stored state being wrong (in either direction). API requests have been updated to handle this in two ways: - Token minting will map a 403 or 404 response to the suspended/uninstalled state (checking first to ensure that it's not some other ephemeral failure or rate limit error). If we got the error because the app had been uninstalled but is now reinstalled, we'll adopt the new installation ID. - 403 or 404 errors for cached installation tokens will drop the token and try again (limited to once per minute). - If we have a stored non-active status, we'll recheck that state (also limited to once per minute) before refusing to mint a new token. # GitHub reconnect The reconnect action for suspended/uninstalled accounts will first try to verify that state (in case of a missed webhook delivery), and if it's still an issue, will deep link the user to the relevant page where they can fix it. Testing Done: - Ran unit tests. - Suspended and deleted app installs and saw that the state was properly reflected in the connected services list. - Reconnected suspended and deleted app installs and saw that state healed correctly.	ummslvyqxyoqyzlozxkmksvtrxvnrpwn

Diff:

Revision 2 (+5448 -340)

Show changes

	reviewboard/admin/views.py
	reviewboard/admin/tests/test_connected_services_list_view.py
	reviewboard/hostingsvcs/base/hosting_service.py
	reviewboard/hostingsvcs/github/accounts.py
	reviewboard/hostingsvcs/github/api.py
	reviewboard/hostingsvcs/github/client.py
	reviewboard/hostingsvcs/github/service.py
	reviewboard/hostingsvcs/github/views.py
	8 more

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

reviewboard/admin/views.py (Diff revision 1)

reviewboard/admin/views.py (Diff revision 1)