Skip to content

Add rspec-time-guard to catch hanging specs - #33

Draft
apiology wants to merge 3 commits into
masterfrom
pin-caching-1-rspec-time-guard
Draft

Add rspec-time-guard to catch hanging specs#33
apiology wants to merge 3 commits into
masterfrom
pin-caching-1-rspec-time-guard

Conversation

@apiology

@apiology apiology commented Aug 2, 2026

Copy link
Copy Markdown
Owner

Extracted from castwide#1006 (Improve pin caching), piece 1 of a chain of PRs breaking that PR into independently-reviewable units before sending them upstream.

Adds a 60s global time limit on specs via the rspec-time-guard gem. Pure dev/test tooling, no runtime behavior change. Independent of the rest of the pin-caching work.

See castwide#1239 for the full rebased PR this is extracted from, and castwide#1006 for the original discussion.

Sets a 60s global time limit on specs via the rspec-time-guard gem.
Extracted from castwide#1006 (Improve pin caching) as a
standalone piece: this is dev/test tooling only, no runtime behavior
change, and useful independently of the rest of that PR.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@apiology
apiology marked this pull request as draft August 2, 2026 15:52
CI showed the new 60s global time limit tripping on 5 specs that are
legitimately slow (gem/bundle resolution, YAML/Thor lookups) rather
than hung: ApiMap#get_method_stack's YAML/Thor cases,
ApiMap#returns core methods, Host#opens a file outside of prepared
libraries, Protocol#handles $/solargraph/documentGems, and
Gemspecs#fetch_dependencies's external-bundle cases. Tag each with the
same per-example time_limit_seconds override the original PR
(castwide#1006) settled on, so this PR doesn't regress CI
on its own before the rest of that PR's stacked branches land.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The YAML/Psych stdlib resolution spec timed out at 240.33s against a
240s limit in CI - a genuine near-miss (0.14% over), not contention
from running multiple PRs' CI concurrently (each job gets its own
runner, so concurrent jobs affect queue time, not execution time).
Widen that limit and the other 120s limits proportionally to give
real headroom against normal run-to-run variance on GitHub Actions'
shared runners, rather than re-running and hoping.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant