Gracefully handling Tds connection errors

Questions / Help
, ,
1

Hey all,

I’ve an Oban worker making a connection to a remote MSSQL DB to run a query and then process the results.

We’re using Tds to manage this and it works great when everything’s set up correctly.

Every now and again the underlying VPN isn’t established and despite the correct DB creds, the connection will fail resulting in a logged error:
[error] Tds.Protocol (#PID<0.864.0>) failed to connect: ** (Tds.Error) tcp connect: econnrefused

My frustration is that the initial connection function start_link/1 will almost always return {:ok, <pid>} so attempts to have a try rescue block aren’t matching – even without DB creds I get the ok tuple then a :killed error and shell reset (locally).

I’m hoping to to find a way to catch this error, handle the case and let the worker just retry. A Sentry issue is pointing to DBConnection for the source of the error, but I’m not certain how I can use that info.

Appreciate any insight :+1:

2

Any exception or crash that happens in a perform/1 block is already captured and converted into an Oban.PerformError for exceptions, or Oban.CrashError for an exit. You don’t have to add any special handling to handle the case and let the worker retry.

3

So, the logged messaging wasn’t interfering with the worker’s performance, just a ping from DBConnection internals.

As queries do fail when the connection is improper, but work even when logs are streaming (this is mostly a local IEx problem), I’ve opted instead of filter out the logging. :person_shrugging:

1 Like