(feature) migrate relay proxy from labstack/echo v4 to v5

[thomaspoignant]

Summary

Migrate the relay proxy from github.com/labstack/echo/v4 to github.com/labstack/echo/v5 to benefit from the latest improvements, bug fixes, and API changes introduced in Echo v5.

Motivation

Echo v5 brings several improvements over v4:

• Cleaner, more consistent API
• Better error handling
• Improved routing
• Active development and support

Scope

The migration touches cmd/relayproxy/ and cmdhelpers/api/middleware/.

Dependencies to update

Current	Target
github.com/labstack/echo/v4 v4.15.2	github.com/labstack/echo/v5
github.com/labstack/echo-contrib	Check v5 compatibility or find alternatives
go.opentelemetry.io/contrib/instrumentation/github.com/labstack/echo/otelecho	Check v5 compatibility

Middleware to validate

All existing middleware must keep working after the migration:

Built-in middleware (currently from echo/v4/middleware):

• middleware.BodyDumpWithConfig — used for debug logging
• middleware.CORSWithConfig — CORS support
• middleware.Recover — panic recovery

Third-party middleware:

• echoprometheus.NewMiddlewareWithConfig (from echo-contrib) — Prometheus metrics
• otelecho.Middleware — OpenTelemetry tracing

Custom middleware (cmd/relayproxy/api/middleware/):

• KeyAuthExtended — API key authentication (user + admin)
• VersionHeader — adds version header to responses
• StreamAuthorizer — SSE stream authorization
• AuthMiddlewareErrHandler — custom auth error handler

Helper middleware (cmdhelpers/api/middleware/):

• ZapLogger — structured request logging with Zap

Acceptance Criteria

• All middleware listed above works correctly after migration
• All existing tests pass
• No regression in authentication, CORS, metrics, tracing, or logging
• echo-contrib and otelecho updated or replaced with v5-compatible alternatives
• Lambda adapter (api/aws_lambda.go) still works

Notes

Echo v5 introduced breaking changes from v4. Key API differences to review:

• echo.Context interface changes
• Middleware signature changes
• Error handler changes
• Router API changes

Check the Echo v5 migration guide before starting.

[100NikhilBro]

Hi @thomaspoignant,

I started investigating the Echo v5 migration and migrated the cmd/relayproxy/api package imports to Echo v5 to identify compatibility issues.

Current blockers found:

• github.com/awslabs/aws-lambda-go-api-proxy v0.16.2 appears to still expect Echo v4 types. The Lambda adapters (echoadapter.New, NewV2, NewALB) fail with type mismatches when passed *echo/v5.Echo.
• github.com/pablor21/echo-etag/v4 returns echo/v4.MiddlewareFunc, which causes type incompatibilities once the API package is moved to Echo v5.
• Additional type mismatches appear in handlers and middleware that still use echo/v4.Context, which is expected and can be addressed as part of the migration.

Before continuing, is there a preferred Echo v5-compatible replacement (or planned migration path) for:

1. aws-lambda-go-api-proxy/echo
2. echo-etag

Or should support for these dependencies be reworked as part of this migration effort?

Thanks!

[thomaspoignant]

Hey @100NikhilBro, thanks for looking into this!
My preference here is to rely on proper Go module releases as much as possible rather than forking or vendoring workarounds for the dependencies that aren't v5-ready yet (echo-contrib, otelecho). Keeping everything on tagged module versions makes maintenance much simpler in the long run.
So I'm happy to hold off on this migration until v5-compatible versions of those are published. No rush on my side — once the ecosystem catches up we can pick it back up.

[100NikhilBro]

Thanks for the clarification!

That makes sense. I'll leave the migration on hold for now and keep an eye on the ecosystem dependencies. Happy to revisit it once v5-compatible releases become available.

Thanks!