Skip to content

2.1.21: CustomProperties plugin still crashes — modifyProperty() calls renamed octokit methods #981

Open

Description

@AdrienJ25

Problem Description

What is actually happening

lib/plugins/custom_properties.js calls two octokit methods that no longer exist in @octokit/plugin-rest-endpoint-methods@17 (transitively pulled in by octokit@^5.0.2 and probot@^14.2.4):

  • octokit.rest.repos.getCustomPropertiesValues → customPropertiesForReposGetRepositoryValues
  • octokit.rest.repos.createOrUpdateCustomPropertiesValues → customPropertiesForReposCreateOrUpdateRepositoryValues

The rename is a documented breaking change in @octokit/plugin-rest-endpoint-methods v17.0.0:

BREAKING CHANGES

  • Several custom property endpoints changed ID

Concrete failure chain on a PR that adds any per-repo custom_properties: block:

  1. find() (line 43) calls paginate(undefined, ...). paginate falls back to GET https://api.github.com/, returns the API root JSON wrapped as a 1-item array. Log says Found 1 custom properties but no values were actually fetched.
  2. The 2.1.21-patched normalize() defensively skips that bogus entry → target [] with source [{...}].
  3. Diff thinks the property is a brand-new addition → add() → modifyProperty('Create', ...).
  4. modifyProperty() (line 113) accesses this.github.rest.repos.createOrUpdateCustomPropertiesValues.endpoint(params). The method is undefined → synchronous TypeError.
  5. The throw escapes Promise.all in Settings.updateRepos → unhandled rejection → Node exits 1 → container restarts. The PR check-run created at validation start is never closed, so the validator is stuck IN_PROGRESS indefinitely.

#971 was closed as fixed in 2.1.21, but #978 only patched the symptom in normalize(). The original reporter never reached modifyProperty() because they crashed earlier. With the normalize fix in place, we now reach the next call and die there — same root cause (the v17 rename), different line.

What is the expected behavior

CustomProperties should call the renamed methods (or use octokit.request("GET /repos/{owner}/{repo}/properties/values") / ("PATCH /repos/{owner}/{repo}/properties/values") to be stable across endpoint-methods versions).

The if (this.nop) branch should also be wrapped in try/catch so a single misconfiguration cannot crash the whole reconcile.

Error output, if available

DEBUG (event): Getting all custom properties for the repo <org>/<repo>
DEBUG (octokit): GitHub request: GET https://api.github.com - 200
DEBUG (event): Found 1 custom properties
DEBUG (event):  [] [{"name":"<prop>","value":"<value>"}]
DEBUG (event): Results of comparing CustomProperties diffable target [] with source [...] is {"msg":"Changes found","additions":{"0":{"name":"<prop>","value":"<value>"}},"modifications":{}}

/opt/safe-settings/lib/plugins/custom_properties.js:113
        this.github.rest.repos.createOrUpdateCustomPropertiesValues.endpoint(params),
                                                                    ^
TypeError: Cannot read properties of undefined (reading 'endpoint')
    at CustomProperties.modifyProperty (/opt/safe-settings/lib/plugins/custom_properties.js:113:69)
    at CustomProperties.add (/opt/safe-settings/lib/plugins/custom_properties.js:88:17)
    at /opt/safe-settings/lib/plugins/diffable.js:115:33
    at Array.forEach (<anonymous>)
    at /opt/safe-settings/lib/plugins/diffable.js:109:25
    at async Promise.all (index 1)
    at async Settings.updateRepos (/opt/safe-settings/lib/settings.js:384:30)
    at async Promise.all (index 0)
    at async Settings.syncAll (/opt/safe-settings/lib/settings.js:24:7)

100% reproducible.

Context

Are you using the hosted instance of probot/settings or running your own?

Self-hosted, official upstream image ghcr.io/github/safe-settings:2.1.21 on Kubernetes.

If running your own instance, are you using it with github.com or GitHub Enterprise?

github.com (Enterprise Cloud plan, not Enterprise Server).

Version of probot/settings

  • safe-settings: 2.1.21
  • probot: 14.2.4
  • octokit: 5.0.5
  • @octokit/plugin-rest-endpoint-methods: 17.0.0

Version of GitHub Enterprise

N/A — Enterprise Cloud, not Server.

Activity

  1. ptemmer commented on May 13, 2026

    @ptemmer

    same issue

  2. breymander commented on May 14, 2026

    @breymander

    We are seeing this as well

  3. decyjphr commented on May 19, 2026

    @decyjphr
    Collaborator

    I had to go back to 2.18 and find a stable version and I am working backwards to resolve this. The branch is yadhav/fix-recent-issues
    It will take me a week to get these merged back to the latest version.
    In the process I have added an end-to-end smoke test script (smoke-test.js) that validates safe-settings against a live GitHub organization. This should help us to smoke test future changes and ensure it is not so flakey.

  4. ptemmer commented on Jun 30, 2026

    @ptemmer

    Any update on when a fix will be released?

  5. breymander commented on Jul 16, 2026

    @breymander

    Since this has been open a while, I opened #1032 with a focused fix for the immediate breakage: it renames the three call sites in lib/plugins/custom_properties.js to the v17 method names (repos.customPropertiesForReposGetRepositoryValues / repos.customPropertiesForReposCreateOrUpdateRepositoryValues) and updates the unit-test mocks to match. The full unit suite passes.

    This restores custom-properties sync in both apply and nop modes: the silent GET / read fallback, the per-repo is not a function write failures, and the nop-mode crash all trace back to the same two renamed methods.

    Not intended to preempt the broader rework in #990. It's a minimal patch to unblock custom properties in the meantime, and should be trivial to carry into or drop in favor of that effort. Happy to adjust the approach if you'd rather use raw request routes (immune to future endpoint-ID renames); noted as an option in the PR.

  6. breymander commented on Jul 20, 2026

    @breymander

    @decyjphr thoughts on this?

  7. 3rwww1 commented on Sep 20, 2026

    @3rwww1

    Hi, any news on this? @breymander @decyjphr?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions