fix(deps): pin go-libs/v5 to v5.6.1 instead of an unresolvable pseudo-version

[flemzord]

Auth pins go-libs/v5 v5.1.1-0.20260522083443-d2a60ed2e0dd. That SHA is a pre-squash intermediate commit of go-libs PR #604 (refactor: split audit package for protocol independence). It is not reachable from any branch or tag in go-libs, so the Go module proxy cannot resolve it:

go: github.com/formancehq/go-libs/v5@v5.1.1-0.20260522083443-d2a60ed2e0dd:
    invalid version: unknown revision d2a60ed2e0dd

Reproduce with an empty module cache:

GOMODCACHE=$(mktemp -d) go list -m github.com/formancehq/go-libs/v5

Builds only succeed on machines that already have the revision cached locally. CI on main has been failing since 2026-07-24.

Audit middleware fixes also picked up

The pinned revision predates even the squashed #604 merge, so auth currently runs the audit middleware without any of its fixes:

go-libs fix	First tag
#610 fix(audit): async http audit publishing	v5.3.2
#620 fix(audit): require shared secret to honor audit-handled header (EN-1152)	v5.4.0
#647 fix(audit): cap captured request/response bodies and flag truncation	v5.4.0
#656 feat: add query params to audit logs	v5.6.0

Auth calls the middleware in pkg/api/module.go with WithSensitivePaths("/api/auth/oauth/token"), so it is actively affected — notably by synchronous publishing on the token endpoint path.

Scope

go.mod / go.sum only. No source changes needed — httpaudit.Middleware and httpaudit.WithSensitivePaths keep backward compatible signatures.

Targeting v5.6.1 rather than v5.7.0: v5.6.1 is what ledger, payments, wallets and reconciliation already run, and v5.7.0 adds an unrelated pkg/errors → stdlib refactor.

Validation

• go build ./... — clean
• go test -race -count=1 ./... — all packages pass
• Resolves from an empty module cache against proxy.golang.org
• No replace directives added (the pre-existing pkg/client replace is untouched)

Note for reviewers

Auth publishes audit events to topic "audit", while webhooks and reconciliation publish to "audit-events". This PR does not change that — flagging it as a possible inconsistency worth a separate look, since changing the topic alters event routing.

This unblocks tagging auth v2.5.0, which is currently impossible with a non-reproducible build.

https://claude.ai/code/session_01Tb7rgNz6hGo2wGBTmymPL1

Summary by CodeRabbit

• Chores
  • Updated an internal library dependency to a newer stable release.

[coderabbitai]

Warning

Review limit reached

@flemzord, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 50 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: cde5466a-6eaa-4045-885a-f9798ad83fc7

📥 Commits

Reviewing files that changed from the base of the PR and between 39f451f and 3680ec3.

📒 Files selected for processing (3)

• cmd/serve.go
• cmd/serve_test.go
• pkg/api/module.go

📝 Walkthrough

Walkthrough

The PR updates the direct github.com/formancehq/go-libs/v5 dependency from a dated pseudo-version to v5.6.1.

Changes

Dependency update

Layer / File(s)	Summary
Update go-libs version go.mod	The direct github.com/formancehq/go-libs/v5 dependency now uses v5.6.1.

Estimated code review effort: 1 (Trivial) | ~2 minutes

Possibly related PRs

• formancehq/auth#132: Updates the same direct github.com/formancehq/go-libs dependency to a different version target.

Suggested reviewers: gfyrag

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: pinning go-libs/v5 to v5.6.1 to replace an unresolvable pseudo-version.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches 💡 1

🛠️ Fix failing CI checks 💡

• Fix failing CI checks

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/bump-go-libs-resolvable-version

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[NumaryBot]

🛑 Changes requested — automated review

The dependency pin from an unresolvable pseudo-version to go-libs/v5 v5.6.1 is the right direction, but it introduces a silent behavioral regression: the new library version defaults audit event publishing to disabled. Existing auth wiring passes only WithSensitivePaths when constructing the HTTP audit middleware, which is no longer sufficient to enable publishing. Additionally, a newly introduced --audit-enabled flag defaults to false, meaning all existing deployments will silently lose their audit trail unless they are explicitly updated. Both issues must be addressed — either by defaulting the flag to true or by explicitly opting the middleware back in — before this change is safe to merge.

Findings outside the diff

🔴 [blocker] Audit middleware disabled by default after go-libs v5.6.1 bump — pkg/api/module.go _{(NumaryBot, codex)}

With go-libs/v5 at v5.6.1, httpaudit.Middleware now defaults 'enabled' to false and skips publishing unless callers explicitly opt in (e.g. by passing httpaudit.WithEnabled(true) or httpaudit.WithConfig(...)). The existing auth wiring in pkg/api/module.go only passes WithSensitivePaths, so after this bump every request silently skips audit publication entirely. This is a behavioral regression: audit events that previously fired on every request are now dropped unless all deployments are updated.

Suggestion: Pass httpaudit.WithEnabled(true) (or an equivalent config option) when constructing the middleware in pkg/api/module.go, or ensure that the audit flag introduced in cmd/serve.go defaults to true so that existing deployments retain the previous publishing behavior.

[NumaryBot]

NumaryBot posted 1 new inline finding.

Summary: #149 (comment)

[flemzord]

Addressed the blocker in 3680ec3, and it surfaced a pre-existing issue worth calling out.

Auth mounted the audit middleware unconditionally, with no flag to turn it off. On the previously pinned go-libs revision the middleware had no enabled option at all, so audit was running on every request — including /api/auth/oauth/token — with the unfixed synchronous publisher. The bump alone would have flipped that to a silent no-op.

Rather than hardcode WithEnabled(true), auth is now wired to the go-libs audit config:

• audit.AddFlags / audit.ConfigFromFlags in cmd/serve.go, httpaudit.WithConfig(auditConfig) in pkg/api/module.go
• audit is opt-in via --audit-enabled, default false
• --audit-handled-header-secret is now configurable, so the EN-1152 fix can actually be used

cmd/serve_test.go covers both the default-off behaviour and explicit enablement, mirroring TestAuditEnabledDefaultsToFalse in webhooks.

Note this is a deliberate behaviour change: auth stops emitting audit events unless the flag is set.

[NumaryBot]

NumaryBot posted 1 new inline finding.

Summary: #149 (comment)

[NumaryBot]

🟠 [major] New --audit-enabled flag defaults to false, silently dropping audit trail

audit.ConfigFromFlags returns Enabled=false because the newly added audit flag defaults to false. Deployments that are not explicitly updated with --audit-enabled will have no audit trail after this change, with no warning or migration path. This is a silent regression for all existing deployments.

Suggestion: Default the --audit-enabled flag to true to preserve backward compatibility with the pre-bump behavior, or emit a prominent deprecation/warning when audit events are disabled.

[flemzord]

Responding to the two findings.

go.mod:11 — "Enable audit middleware after bumping go-libs" — stale, already addressed in 3680ec3. pkg/api/module.go now passes httpaudit.WithConfig(auditConfig) alongside WithSensitivePaths, so the middleware is driven by the audit config rather than left at the zero-value default.

cmd/serve.go:193 — "defaults to false, silently dropping audit trail" — acknowledged, but keeping false deliberately. Two reasons:

1. There is no audit trail to drop. The audit middleware landed in #143 on 2026-05-22. The currently released and deployed version is v2.4.3, tagged 2026-03-02 — #143 is 18 commits ahead of it. No production deployment of auth has ever emitted an audit event, so this is not a regression against any shipped behaviour. It only changes unreleased main.

2. Opt-in is the intended posture for the stack. The audit middleware shipped with defects that are still only partially mitigated — notably #620/EN-1152, where the audit-handled dedup header is honored without a shared secret unless one is configured, and no service in the stack configures one today. Turning audit on by default would enable that path unconditionally on the OAuth token route.

For reference, go-libs' own audit.AddFlags defaults audit-enabled to false, and webhooks does the same. This PR aligns auth with that default rather than diverging from it.

The flag and --audit-handled-header-secret are both exposed, so enabling audit is a one-line deployment change once the header-secret rollout is agreed stack-wide.