Data race due to global instance of openapi3gen.Generator

[loikg]

To Reproduce Create multiple instance of fuego.Server in different goroutines. I have create a simple repository to showcase the problem over here. But for sake of completeness here the test used:

package main

import (
    "fmt"
    "testing"

    "github.com/go-fuego/fuego"
)

func TestDataRace(t *testing.T) {
    t.Parallel()

    for n := range 2 {
        t.Run(fmt.Sprintf("create server %d", n), func(t *testing.T) {
            t.Parallel()
            createFuegoServer(t)
        })
    }
}

func createFuegoServer(t *testing.T) {
    t.Helper()

    server := fuego.NewServer()
    fuego.Get(server, "/", func(ctx *fuego.ContextNoBody) (any, error) {
        return nil, nil
    })
}

Expected behavior The data race should not happen.

Framework version: Tested on v0.14.0 and main at the time of writing (f386d4f).

Go version: v1.23.2

Additional context This prevent running tests that exercise the entire server in parallel, but does not affect unit test of handlers as far as I understand. The root cause is the package global variable generator at line 151 in openapi.go being shared and concurrently used by every fuego.Server instances. See #202 for a potential fix.

Huge thanks for your work, I really enjoy using fuego!

[EwenQuim]

Wow I didn't thought that someone would use several instances of fuego.Server haha.

Just a side question : why do you need that?

Thanks for raising this issue :)

[loikg]

No worries. The reason is purely to be able to run tests in parallel.

I took the habit of making every test that I can run in parallel with t.Parallel() and in some of my tests I want to test the entire "stack" including middlewares that should be trigger when calling a specific endpoint, thus these tests create multiple fuego.Server instances in parallel leading to the data race.

[EwenQuim]

Very good idea indeed