Repository navigation
2.1.21: CustomProperties plugin still crashes — modifyProperty() calls renamed octokit methods #981
Description
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→customPropertiesForReposGetRepositoryValuesoctokit.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:
find()(line 43) callspaginate(undefined, ...). paginate falls back toGET https://api.github.com/, returns the API root JSON wrapped as a 1-item array. Log saysFound 1 custom propertiesbut no values were actually fetched.- The 2.1.21-patched
normalize()defensively skips that bogus entry →target [] with source [{...}]. - Diff thinks the property is a brand-new addition →
add()→modifyProperty('Create', ...). modifyProperty()(line 113) accessesthis.github.rest.repos.createOrUpdateCustomPropertiesValues.endpoint(params). The method isundefined→ synchronous TypeError.- The throw escapes
Promise.allinSettings.updateRepos→ unhandled rejection → Node exits 1 → container restarts. The PR check-run created at validation start is never closed, so the validator is stuckIN_PROGRESSindefinitely.
#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
ptemmer commentedon May 13, 2026
same issue
breymander commentedon May 14, 2026
We are seeing this as well
decyjphr commentedon May 19, 2026
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-issuesIt 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.
ptemmer commentedon Jun 30, 2026
Any update on when a fix will be released?
breymander commentedon Jul 16, 2026
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.jsto 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-repois not a functionwrite 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.
breymander commentedon Jul 20, 2026
@decyjphr thoughts on this?
3rwww1 commentedon Sep 20, 2026
Hi, any news on this? @breymander @decyjphr?