replace log with slog

[pmenglund]

found a few more places where log is used instead of slog

[brandur]

Okay this one's a bit tricky in that it's unfortunately failing example tests when changed to slog because especially in CI tests can finish before the notifier's able to connect, and by the time it's done trying to, it may produce a connection error (rather than a context cancelled error which is handled above), which shows up in test output and fails example tests.

Change this line to this:

		// Log at a lower verbosity level in case an error is received when the
		// context is already done (probably because the client is stopping).
		// Example tests can finish before the notifier connects and starts
		// listening, and on client stop may produce a connection error that
		// would otherwise pollute output and fail the test.
		select {
		case <-ctx.Done():
			n.logger.Info("error establishing connection from pool", "err", err)
		default:
			n.logger.Error("error establishing connection from pool", "err", err)
		}

It's a little hacky, but it seems to get the tests passing again.

[bgentry]

I'm wondering if we have a better way to "fix" this, although it's really only an issue for example tests so it may not warrant much effort 🤔

[brandur]

Yeah, there probably is, but I couldn't think of a particularly easy alternative and was thinking that it might be better just to patch it for now, and try to think of something else.

LMK, if you have any ideas. FWIW, here's what a failing build looks like with a more detailed error:

https://github.com/riverqueue/river/actions/runs/7380506104/job/20077953005

error establishing connection from pool: failed to connect to host=127.0.0.1 user=postgres database=river_testdb_example: failed SASL auth (write failed: write tcp 127.0.0.1:42510->127.0.0.1:5432: i/o timeout)

Unfortunately, it's a fairly broad error and it wasn't super obvious to me how to handle it while being sure it's a stop-related error as opposed to something else.

[bgentry]

I wonder if we can make use of context.WithCancelCause to cancel the context with a specific error type during shutdown? Then we could check if the context was cancelled and the cause was a shutdown before logging the error here.

I did something similar in #141.

[brandur]

K good idea on this one. I think this rabbit hole may be a little deep to ask for in what should've been a fairly simple third party contribution like this one, but I put it on my list of things to investigate further.