Skip to content

Reduce sandboxing to prevent swallowed deprecations #2857

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

pirj
Copy link
Member

@pirj pirj commented Aug 6, 2025

We used to sandbox everything, but it turns out that deprecations were swallowed, as the temporary config has no deprecation stream set, or stderr is masked.
Found here #2849 (comment)

We're almost back to square one with deprecations as we were before #2365

However, I'm not entirely happy with this approach. We still mute deprecations for those Rails-related example group specs and a few others, and there are chances deprecations will pop up there eventually.

❓ Would it be better to replay the configuration block on top of the sandboxed configuration? Probably not, and it might not work if stderr is intercepted.

Please consider this WIP

We used to sandbox everything, but it turns out that deprecations were
swallowed, as the temporary config has no deprecation stream set, or
stderr is masked.
    RuntimeError:
       Warnings were generated: /home/runner/work/rspec-rails/rspec-rails/lib/rspec/rails/matchers/have_http_status.rb:219: warning: Status code :unprocessable_entity is deprecated and will be removed in a future version of Rack. Please use :unprocessable_content instead.
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