Skip to content

Troubleshooting

An issue I recently changed in GitHub has not changed in Pealboard

Section titled “An issue I recently changed in GitHub has not changed in Pealboard”

Pealboard is told by a GitHub webhook, usually within a second. If it has not arrived:

  1. Open the issue. Anything older than 60 seconds is re-read from GitHub when a member opens it, so opening it often fixes it by itself.
  2. Check the “Synced” line under the issue. It says when Pealboard last read the object, and if the last attempt failed it says what failed and when the next attempt is.
  3. Go to Settings → GitHub and select Sync now.

Reconciliation runs every hour for every repository and repairs anything a dropped webhook missed, so a delay is always bounded by an hour even if nobody does anything.

Check these in order.

  1. Is it in the installation? Go to Settings → GitHub → Change repositories on GitHub. If the installation is set to Only select repositories and yours is not in the list, Pealboard cannot see it at all.
  2. Was the installation approved? If you are not a GitHub organization owner, your install created a request. Until an owner approves it, nothing is connected. Settings → GitHub says so.
  3. Is it over the plan’s limit? The Free plan connects 3 repositories. If the installation grants more, Settings → GitHub lists them and asks which three are enabled.
  4. Is it a fork, an archived repository or one without Issues turned on? A repository with Issues disabled in GitHub has no issues to read.

Nothing you can do in Pealboard grants access to a repository the installation does not cover. That is GitHub’s boundary and it is the right one.

Almost always, the comment was internal.

  • A comment is public only if you turned on Reply to portal before posting it. A public comment carries a Public badge in the workspace; if the badge is not there, the customer cannot see it.
  • Posting the comment in GitHub rather than in Pealboard makes it internal. There is no way to mark a comment public from GitHub’s own interface.
  • A comment cannot be made public after the fact. Post a new one with Reply to portal turned on.
  • Check the customer can see the request: a request set to Private is visible to its requester, and a colleague of theirs without the manager role will not see it or its comments.
  • They may have selected Stop emailing me about this request.
  • Status-change email is sent on a change of the seven-word status, not on every edit. Moving an issue between two internal Status options that both map to Open is not a status change to a customer.
  • Check the address on their row in Customers. A code-based sign-in proves the address worked at least once.

The message shows GitHub’s own words, prefixed “GitHub refused the write:”. Nothing was changed. The common ones:

GitHub says Means
Resource not accessible by integration The installation does not cover that repository, or the permission was not granted
Not Found The object was deleted in GitHub, or is in a repository outside the installation
Issues are disabled on that repository Turn Issues on in the repository’s GitHub settings
Validation Failed A label, milestone or assignee named in the write no longer exists

Everything is slow, or a backfill has paused

Section titled “Everything is slow, or a backfill has paused”

A GitHub App installation has an hourly request budget, and GitHub’s project data has a separate one. When either falls below a tenth of its limit, Pealboard pauses backfills so that the budget left is spent on what people are actually doing. Writes you make continue during a pause.

Settings → GitHub shows the remaining budget and the time it refreshes. A backfill that paused resumes on its own.

It cannot be moved: GitHub’s API has no way to move an issue between repositories. Open a new issue in the right repository, select Share to portal to attach it to the same portal, and close the original as Not planned.