Protractor test run does not abort after first failure when failFast is enabled with directConnect

Short answer

No — in the Protractor versions where this shows up, failFast is not reliably honored when directConnect: true is set. This is a known framework limitation, not a misconfiguration on your side. The same config typically aborts correctly when you run through a Selenium server (seleniumAddress) instead of connecting directly to the driver.

What's actually happening

failFast is implemented in Protractor's runner, not in Jasmine. After a spec fails, the runner is supposed to tear down the WebDriver session and stop scheduling further specs. With directConnect, Protractor skips the Selenium server and talks to ChromeDriver/GeckoDriver directly — and in several releases the abort path tied to session cleanup was never triggered in that mode. The result: the flag is parsed, no error is shown, and the remaining specs run anyway.

Two clarifications on your sub-questions:

• Runtime override: even when failFast works, it only prevents not-yet-started specs from being scheduled. It never interrupts a spec that is currently executing — that spec runs to completion.
• multiCapabilities / shardTestFiles: these have their own separate known issues with fail-fast behavior (each capability/shard is its own runner context, so a failure in one does not cleanly abort the others). That is independent of the directConnect problem.

How to confirm it on your setup

Behavior varies by exact version, so verify rather than trust the changelog:

1. Check the installed version: npm ls protractor, then search its GitHub issues for "failFast directConnect".
2. Add a temporary console.log (or reporter counter) at the top of the spec that follows your intentionally failing spec.
3. Run once with directConnect: true, then again against a started Selenium server (webdriver-manager start plus seleniumAddress). If the log prints in the first run but not the second, you've confirmed the bug.

Workarounds

• Run through a local Selenium server for CI jobs where fail-fast matters. This is the least invasive fix.
• Gate specs yourself: set a shared flag in an afterEach hook when a spec fails, and short-circuit subsequent specs at their start. Crude, but works in any mode.
• Don't confuse it with Jasmine's stopSpecOnExpectationFailure — that stops the current spec at the first failed expectation; it does not abort the suite.

The bigger picture

Protractor is deprecated and unmaintained, so this will never be fixed upstream. If reliable bail-on-failure matters to your pipeline, the durable fix is migrating to WebdriverIO, Playwright, or Cypress, all of which have supported, documented fail-fast options.