Implementing our own logging as it is done for riverlog

[advdv]

I'm super excited to try the new logging feature. It would really improve our debugging capabilities. Using the riverlog package is easy enough but it would really like our developers to use Uber's zap logger in the worker logic since we use that everywhere else in our codebase.

So i figured i could just copy the riverlog middleware implementation and implement it for our own needs. But it seems that the riverlog package requires a internal package github.com/riverqueue/river/internal/jobexecutor to update the metadata after the job is run. I think, because i can't get seem to get this behavior without the package.

I've found this discussion #476 that touches upon the fact that metadata should be considered immutable but at least the "output" and "river:log" metadata field move away from this.

After some hacking, I did manage to pull it off. But it's ugly:

package work

import (
	"context"
	"fmt"
	"io"
	"log/slog"

	"github.com/riverqueue/river/riverlog"
	"github.com/riverqueue/river/rivertype"
)

type Middleware struct {
	rivertype.WorkerMiddleware
}

func newMiddleware() *Middleware {
	return &Middleware{}
}

// Work implements our middleware such that we can provide workers with a zap.Logger instead of a slog Logger.
func (mw *Middleware) Work(ctx context.Context, job *rivertype.JobRow, doInner func(ctx context.Context) error) error {
	var logw io.Writer
	inner := riverlog.NewMiddleware(func(w io.Writer) slog.Handler {
		logw = w // keep it so we can use for logging our own lines.
		return slog.DiscardHandler
	}, nil)

	return inner.Work(ctx, job, func(ctx context.Context) error {
		fmt.Fprintf(logw, "write my own log lines") // here we could init a zap logger and pass it in our own context.

		return doInner(ctx)
	})
}

[brandur]

Yeah, agreed that riverlog should be usable with non-slog solutions in general. Opened #919.