Page MenuHomePhabricator

When database connection exceptions occur, raise them to the setup layer
ClosedPublic

Authored by epriestley on May 17 2018, 1:03 PM.
Tags
None
Referenced Files
F18200081: D19454.id.diff
Mon, Aug 18, 4:11 AM
F18196356: D19454.diff
Sun, Aug 17, 5:52 PM
F18109962: D19454.id46536.diff
Mon, Aug 11, 3:28 PM
F18109961: D19454.id46535.diff
Mon, Aug 11, 3:28 PM
F18109958: D19454.id.diff
Mon, Aug 11, 3:27 PM
F18104728: D19454.diff
Sun, Aug 10, 1:44 PM
F17819043: D19454.id46535.diff
Jul 26 2025, 12:52 AM
F17807230: D19454.id.diff
Jul 25 2025, 2:42 PM
Subscribers
None

Details

Summary

Ref T13141. Currently, during first-time setup we don't surface all the details about connection exceptions that we could: the underlying exception is discarded inside cluster connection management.

This isn't a huge issue since the reason for connection problems is usually fairly obvious, but in at least one case (see T13141) we hit a less-than-obvious exception.

Instead, store the original exception and propagate the message up the stack so users have more information about the problem.

Test Plan
  • Configured an intentionally bad MySQL username.
  • Restarted Apache and loaded Phabricator.
  • Got a more helpful exception with a specific authentication error message.

Screen Shot 2018-05-17 at 5.56.31 AM.png (968×1 px, 138 KB)

Diff Detail

Repository
rP Phabricator
Branch
ref1
Lint
Lint Passed
Unit
Tests Passed
Build Status
Buildable 20343
Build 27628: Run Core Tests
Build 27627: arc lint + arc unit