Skip to content

Conversation

@nathanl
Copy link
Contributor

@nathanl nathanl commented Oct 28, 2025

The label must be passed in - see elixir-ecto/ecto_sql#698

This is helpful if the application has more than one repo (eg read replicas). For example:

Before: ** (DBConnection.ConnectionError) connection is closed because of an error, disconnect or timeout

After: ** (DBConnection.ConnectionError) MyApp.Repo connection is closed because of an error, disconnect or timeout

Before: ** (DBConnection.OwnershipError) cannot find ownership process for #PID<0.1128.0> ({Phoenix.LiveView, MyAppWeb.FooLive, "lv:phx-GHKljxU3bpZfbx9j"}) using mode :manual

After: ** (DBConnection.OwnershipError) cannot find ownership process for #PID<0.1128.0> ({Phoenix.LiveView, MyAppWeb.FooLive, "lv:phx-GHKljxU3bpZfbx9j"}) using mode :manual on repo MyApp.Repo

using mode #{inspect(mode)}.
using mode #{inspect(mode)} on repo #{inspect(repo)}.
(Note that a connection's mode reverts to :manual if its owner
terminates.)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

on line 381

@josevalim
Copy link
Member

Hi @nathanl. I would prefer to not depend on repo, because it is really not a db_connection configuration or concern. Can you find anything on Process.info(self()) or Process.info(self(), :registered_name) you could use?

@nathanl
Copy link
Contributor Author

nathanl commented Oct 30, 2025

@josevalim good point, but won't 99% of users pass a repo? In maybe_prefix_repo it's optional - would you be satisfied if it were optional everywhere in these messages?

@realglebivanov
Copy link
Contributor

@nathanl would you consider adding some libary-agnostic metadata(contained e.g. in a kw-list) to the exception a viable option?

@nathanl
Copy link
Contributor Author

nathanl commented Nov 3, 2025

@realglebivanov Can you elaborate a bit on what that might look like?

@realglebivanov
Copy link
Contributor

realglebivanov commented Nov 3, 2025

@realglebivanov Can you elaborate a bit on what that might look like?

So, right now DBConnection.ConnectionError contains only message, reason and severity.
Instead of modifying the existing message text, we could add an additional field to the DBConnection.ConnectionError that could contain useful metadata.
Also, in this case we wouldn't have to rely on specific option types, it could be just a keyword list.
Of course, that could cost us an overhead of storing and copying around the list.
Hopefully, I made my point clear.

nathanl added a commit to nathanl/ecto_sql that referenced this pull request Nov 17, 2025
@nathanl nathanl force-pushed the put_repo_name_in_errors branch from 7b008da to 66bd0ec Compare November 17, 2025 16:08
nathanl added a commit to nathanl/ecto_sql that referenced this pull request Nov 17, 2025
@nathanl nathanl changed the title Put the repo name in these errors Put a label (like Repo name) in these errors Nov 17, 2025
The label must be passed in - see elixir-ecto/ecto_sql#698

Assuming it's the repo name, this is helpful if the application has more
than one repo (eg read replicas). For example:

Before: "** (DBConnection.ConnectionError) connection is closed because
of an error, disconnect or timeout"

After: "** (DBConnection.ConnectionError) MyApp.Repo connection is
closed because of an error, disconnect or timeout"
@nathanl nathanl force-pushed the put_repo_name_in_errors branch from 66bd0ec to 2665095 Compare November 17, 2025 16:22
@nathanl
Copy link
Contributor Author

nathanl commented Nov 17, 2025

Updated so that callers can optionally pass a label. If it's the repo name, like in elixir-ecto/ecto_sql#698, it shows up like this:

11:21:51.330 [error] Process #PID<0.1502.0> raised an exception
** (DBConnection.OwnershipError) cannot find ownership process for #PID<0.1502.0> (:erlang)
(GridPoint.Repo) using mode :manual.
(Note that a connection's mode reverts to :manual if its owner
terminates.)

@nathanl
Copy link
Contributor Author

nathanl commented Nov 17, 2025

@josevalim what do you think of this approach?

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.

3 participants