fix: ensure IP restriction error handling for run:inside and logs commands

[michaelmalave]

Summary

Fixed silent failure issue in heroku run:inside and improved error messages in heroku logs when executed outside trusted IP ranges. Added uniform error handling for 403 HTTP responses to provide clear error messages instead of silent failures or generic errors.

Type of Change

• fix: Bug fix or issue (patch semvar update)
• feat: Introduces a new feature to the codebase (minor semvar update)
• perf: Performance improvement
• docs: Documentation only changes
• tests: Adding missing tests or correcting existing tests
• chore: Code cleanup tasks, dependency updates, or other changes

Note: Add a ! after your change type to denote a breaking change.

Testing

yarn && yarn build

Follow guide for staging heroku environment here: staging setup.

get current webserver

heroku ps -a michael-test-fir-app

Confirm ip restrictions (should be empty). Use the remove command if needed:

./bin/run spaces:trusted-ips --space michael-test-fir-space

./bin/run spaces:trusted-ips:remove [range] --space michael-test-fir-space

Run commands against test space + app with IP restrictions enabled:

./bin/run run:inside <webserver> -a michael-test-fir-app ls

./bin/run logs -a michael-test-fir-app --tail

Both should return the same error: Error: You can't access this space from your IP address. Contact your team admin.

Additional Context

• Root Cause:

  • The run:inside command failed silently when IP restrictions were active because the HTTPS request in the SSH connection path received a 403 response but had no handler for it, causing the Promise to hang indefinitely waiting for an upgrade event that never came.
  • The logs command displayed generic error messages for 403 responses because EventSource doesn't expose HTTP response bodies, making it impossible to distinguish between IP restrictions (immediate 403) and stream expiration errors (delayed 403 after messages were received).

• Fix Applied:

  • dyno.ts: Added HTTP response handler in _connect() method to check for 403 status codes before the upgrade event and reject the Promise with a user-friendly error message: "You can't access this space from your IP address. Contact your team admin."
  • log-displayer.ts: Implemented connection state tracking using a hasReceivedMessages flag to distinguish between immediate 403 errors (IP restrictions) and delayed 403 errors (stream expiration). The error handler now:
    • Tracks whether any log messages were received before the 403 error using hasReceivedMessages flag
    • For immediate 403 (no messages received): Shows "You can't access this space from your IP address. Contact your team admin."
    • For delayed 403 (messages were received): Shows "Log stream access expired. Please try again."
    • For 404 with tail enabled: Shows "Log stream access expired. Please try again." for consistency

• Implementation Details:

  • Used connection state tracking instead of fetching response bodies (which EventSource doesn't expose)
  • Added hasReceivedMessages boolean flag that is set to true when the first message event is received
  • The error handler checks this flag to determine if the 403 occurred immediately (IP restriction) or after receiving messages (stream expiration)
  • This approach works around EventSource's limitation of not exposing response bodies in error events

Resolved usage:

Related Issue

Closes @W-20247783@

[tlowrimore-heroku]

Nice! This looks great! I really like the AbortController-based clean-up logic.