fp-go Logging Patterns

fp-go Logging

Logging is a side effect: it must never change the value or the error flowing through a pipeline. fp-go expresses this with the Tap* family of operators. A Tap runs an effect on the current value (or error) and hands the original computation downstream unchanged.

This skill covers three tasks:

1. Add a simple log statement: TapSLog, TapIOK, TapReaderIOK, TapLeft
2. Add entry and exit logs: LogEntryExit
3. Add context to the error channel: MapLeft + errors.OnError, then log once

Examples assume these imports; all live under github.com/IBM/fp-go/v2:

import (
    "log/slog"

    RIO "github.com/IBM/fp-go/v2/context/readerioresult"
    ER  "github.com/IBM/fp-go/v2/errors"
    F   "github.com/IBM/fp-go/v2/function"
    IO  "github.com/IBM/fp-go/v2/io"
    "github.com/IBM/fp-go/v2/logging"
    R   "github.com/IBM/fp-go/v2/result"
)

Runnable versions of the snippets are in v2/context/readerioresult/logging_example_test.go (ExampleTapSLog, ExampleTapIOK_logging, ExampleTapReaderIOK_logging, ExampleSLogRight, ExampleSLogLeft, ExampleLogEntryExit, ExampleLogEntryExit_nested, ExampleLogEntryExitWithCallback, ExampleMapLeft, ExampleMapLeft_logging).

Before You Generate

fp-go is low-frequency in training data, so signatures are easy to misremember. For any combinator not shown below, look it up via the fp-go MCP server's search_examples / get_example tools (see the fp-go-mcp skill) instead of guessing. After writing code, run go build ./... and go vet ./... and fix any type-parameter or argument-order errors before presenting it.

Quick Reference

Tap* and ChainFirst* are aliases (TapIOK = ChainFirstIOK, TapLeft = ChainFirstLeft, …). Prefer the Tap names for logging; they state the intent.

1. A Simple Log Statement with Tap

Default: TapSLog

TapSLog[A](msg) is an Operator[A, A]. Put it in the pipe after the step you want to observe. It logs value=<A> on success or error=<err> on failure at INFO level, using the logger from the context, and returns the computation unchanged.

func greeting(id int) RIO.ReaderIOResult[string] {
    return F.Pipe2(
        fetchUser(id),
        RIO.TapSLog[User]("fetched user"),
        RIO.Map(getName),
    )
}
// level=INFO msg="fetched user" value="{ID:42 Name:Alice}"
// level=INFO msg="fetched user" error="not found"

• Logs happen when the pipeline runs, not when it is built.
• The type parameter is the type at that point in the pipe (User here, not string).
• TapSLogInfo / TapSLogDebug choose the level explicitly. Debug logs cost nothing when the logger's level filters them out.
• context/readerresult and context/readerio have their own TapSLog[A] with the same usage.

Printf-Style: TapIOK with IO.Logf

Any io.Kleisli[A, B] (func(A) IO[B]) can be tapped with TapIOK. The io package has ready-made ones:

RIO.TapIOK(IO.Logf[User]("fetched user %+v"))       // log.Printf
RIO.TapIOK(IO.LogGo[User]("user {{.Name}}"))        // text/template, log.Println
RIO.TapIOK(IO.Printf[User]("fetched user %+v\n"))   // fmt.Printf (stdout, no timestamp)
RIO.TapIOK(IO.Logger[User](myStdLogger)("user"))    // custom *log.Logger

These use the standard log package, not slog, and log only on success; an error skips the tap. Prefer TapSLog when the application uses structured logging.

The same operator exists for the other monads: IOR.TapIOK (ioresult), RR.TapIOK (context/readerresult), IO.ChainFirst (plain IO).

Custom Attributes: TapReaderIOK

When you want a specific message and specific attributes, write a small named func(A) ReaderIO[Void] that reads the logger from the context. Reading from the context means the log uses the request-scoped logger and inherits the correlation ID of an enclosing LogEntryExit.

import RIOC "github.com/IBM/fp-go/v2/context/readerio"

func logUserLoaded(u User) RIOC.ReaderIO[F.Void] {
    return func(ctx context.Context) IO.IO[F.Void] {
        return func() F.Void {
            logging.GetLoggerFromContext(ctx).InfoContext(ctx, "user loaded", "id", u.ID, "name", u.Name)
            return F.VOID
        }
    }
}

pipeline := F.Pipe2(
    fetchUser(42),
    RIO.TapReaderIOK(logUserLoaded),
    RIO.Map(getName),
)
// level=INFO msg="user loaded" id=42 name=Alice

Do not call slog.Info(...) from inside RIO.Map: Map is for pure functions, and the global logger ignores the logger scoped to the context.

Success Only / Error Only

SLogRight and SLogLeft are Kleisli arrows, so they go through Tap / TapLeft:

RIO.Tap(RIO.SLogRight[User]("fetched user"))             // INFO, success only
RIO.TapLeft[User](RIO.SLogLeft("fetching user failed"))   // ERROR, error only; the error still propagates

TapLeft needs the explicit [A] because A cannot be inferred from the error handler.

Common Mistakes

// ❌ SLog is Kleisli[Result[A], Void]: its input is the Result, not A, so this does not compile
RIO.Chain(RIO.SLog[User]("fetched"))
// ✅
RIO.TapSLog[User]("fetched")

// ❌ Chain replaces the value with Void
RIO.Chain(RIO.SLogRight[User]("fetched"))
// ✅
RIO.Tap(RIO.SLogRight[User]("fetched"))

// ❌ side effect inside a pure Map; bypasses the context logger
RIO.Map(func(u User) User { slog.Info("fetched", "user", u); return u })
// ✅
RIO.TapSLog[User]("fetched")

2. Entry and Exit Logs

LogEntryExit[A](name) is an Operator[A, A] that wraps the computation it is applied to. It logs [entering] before that computation starts and [exiting ] (success) or [throwing] (failure, with the error) after it ends. Both records carry the same correlation ID, and the exit record carries the duration.

func loadUser(id int) RIO.ReaderIOResult[User] {
    return F.Pipe1(
        fetchUser(id),
        RIO.LogEntryExit[User]("loadUser"),
    )
}
// level=INFO msg=[entering] ID=7 name=loadUser
// level=INFO msg="[exiting ]" ID=7 name=loadUser duration=1.2ms
//
// on failure:
// level=INFO msg=[entering] ID=8 name=loadUser
// level=INFO msg=[throwing] ID=8 name=loadUser duration=0.4ms error="not found"

What Gets Wrapped

In a F.Pipe, LogEntryExit wraps everything above it. Put it last to time a whole function, or apply it to a single step to time just that step:

// Whole pipeline: the TapSLog runs between entry and exit and is logged with the same ID
loadName := F.Pipe3(
    fetchUser(42),
    RIO.TapSLog[User]("fetched user"),
    RIO.Map(getName),
    RIO.LogEntryExit[string]("loadName"),
)
// level=INFO msg=[entering] ID=3 name=loadName
// level=INFO msg="fetched user" ID=3 value="{ID:42 Name:Alice}"
// level=INFO msg="[exiting ]" ID=3 name=loadName duration=…

// One step inside a larger pipeline: wrap the Kleisli, not the pipeline
F.Pipe2(
    fetchUser(42),
    RIO.Chain(F.Flow2(fetchOrders, RIO.LogEntryExit[[]Order]("fetchOrders"))),
    RIO.Map(summarize),
)

Nested LogEntryExit calls each get their own ID. The ID is installed on the context logger for the wrapped computation, so every context-aware log inside it (TapSLog, SLogLeft, TapReaderIOK using GetLoggerFromContext) is correlated automatically.