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

[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.

[ptemmer]

same issue

[breymander]

We are seeing this as well