@feigi/fleet-ctl 3.81.3 → 3.81.4
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json
CHANGED
|
@@ -47,14 +47,25 @@ bill a second one that `rate_limit` does not report; the boundary is per route,
|
|
|
47
47
|
so `actions/runs/<id>/jobs` is on the reported counter. Every response says
|
|
48
48
|
`X-Ratelimit-Resource: core`, so only the reset epoch and the used sequence tell
|
|
49
49
|
the two apart, and the unreported bucket's remaining count is readable only from
|
|
50
|
-
the `X-Ratelimit-Remaining` header of a call that bills it.
|
|
51
|
-
|
|
50
|
+
the `X-Ratelimit-Remaining` header of a call that bills it. GitHub's REST
|
|
51
|
+
rate-limit documentation does not describe this bucket (it says `core` covers
|
|
52
|
+
"all non-search-related resources in the REST API"), so the gate rests on
|
|
53
|
+
measurement (2026-10-13 and 2026-10-19), not on documentation. **A second pass
|
|
54
|
+
gate therefore probes it too**: one `gh api -i` read of
|
|
52
55
|
`actions/workflows?per_page=1` per tick, 1 unit of that bucket (measured
|
|
53
56
|
2026-10-13: its remaining count fell by 1 per call while `rate_limit` stood
|
|
54
57
|
still, and its reset epoch differed from `rate_limit`'s). A `ci-state` call
|
|
55
58
|
spends 4 units of it on the common path — one `gh run list` and one `gh run view`
|
|
56
59
|
cost 2 each (measured the same day) — so it is held to the same `200 + 4 × count`
|
|
57
|
-
reserve.
|
|
60
|
+
reserve. 4 is the most one call spends on this bucket for a repo with at most 100
|
|
61
|
+
workflows: 0 with no CI, 2 with no run on the PR's head, 4 otherwise. The
|
|
62
|
+
dropped-required-jobs path adds only reported-bucket calls, and the workflow-name
|
|
63
|
+
lookup pages 100 workflows per page, so a repo with more pays more per call. The
|
|
64
|
+
bucket is account-wide, not per repository: probes on three unrelated
|
|
65
|
+
repositories drew one countdown and one reset epoch (measured 2026-10-19), so
|
|
66
|
+
another run on the same token, or any `gh run` use, spends it, and its
|
|
67
|
+
DEGRADED line can fire with few open PRs on this repository. It has its own
|
|
68
|
+
global latch (`hidden_out`) and its DEGRADED and
|
|
58
69
|
RECOVERED lines name it, so a pause on this bucket is not misread as the
|
|
59
70
|
reported budget running low. An unreadable header is an outage here exactly as a
|
|
60
71
|
non-numeric `rate_limit` read is. The probe runs only when the reported-bucket
|