Guard maps in legacy handler

[Sayan-]

Overview

While doing some local stress testing I actually hit the case where concurrent map writes caused us to crash out:

[neko] fatal error: concurrent map writes

[neko] goroutine 5642 [running]:
[neko] internal/runtime/maps.fatal({0x13955ef?, 0x0?})
	/usr/local/go/src/runtime/panic.go:1046 +0x20
[neko] internal/runtime/maps.(*Map).Delete(0x40001157a0, 0x1260ce0, 0x40021b7438)
	/usr/local/go/src/internal/runtime/maps/map.go:652 +0x48
[neko] github.com/m1k1o/neko/server/internal/http/legacy.(*session).destroy(0x40032ea5a0)
	/src/internal/http/legacy/session.go:207 +0xd0
[neko] github.com/m1k1o/neko/server/internal/http/legacy.(*LegacyHandler).Route.func1({0xffff4dcc1c60, 0x400213b8c0}, 0x4002860140)
	/src/internal/http/legacy/handler.go:212 +0x794

Fixing for reliability!

I also had gpt-5 scan the internal implementation for any similar cases, resulting in c667c74

Testing

CI

[mesa-dot-dev]

Mesa Description

Overview

While doing some local stress testing I actually hit the case where concurrent map writes caused us to crash out:

[neko] fatal error: concurrent map writes

[neko] goroutine 5642 [running]:
[neko] internal/runtime/maps.fatal({0x13955ef?, 0x0?})
	/usr/local/go/src/runtime/panic.go:1046 +0x20
[neko] internal/runtime/maps.(*Map).Delete(0x40001157a0, 0x1260ce0, 0x40021b7438)
	/usr/local/go/src/internal/runtime/maps/map.go:652 +0x48
[neko] github.com/m1k1o/neko/server/internal/http/legacy.(*session).destroy(0x40032ea5a0)
	/src/internal/http/legacy/session.go:207 +0xd0
[neko] github.com/m1k1o/neko/server/internal/http/legacy.(*LegacyHandler).Route.func1({0xffff4dcc1c60, 0x400213b8c0}, 0x4002860140)
	/src/internal/http/legacy/handler.go:212 +0x794

This PR fixes the fatal race condition by adding a sync.Mutex to the LegacyHandler. This ensures that all read and write operations on the sessionIPs and bannedIPs maps are thread-safe, preventing the server from crashing under concurrent requests.

Testing

CI

^{Description generated by Mesa. Update settings}

[mesa-dot-dev]

Performed full review of 560fac5...ac19476

Analysis

1. While the PR addresses concurrent map access with mutexes, there's no mention of performance impact analysis for high-traffic scenarios where lock contention could become an issue
2. The solution seems to focus only on mutex-based synchronization rather than considering alternative concurrency patterns (like sync.Map or read-write locks) that might offer better performance characteristics
3. There's no indication of comprehensive testing to verify the fix works under actual concurrent load conditions

Tip

Help

Configure your agents

Mesa Docs

Slash Commands:

• /review - Request a full code review
• /review latest - Review only changes since the last review
• /describe - Generate PR description. This will update the PR body or issue comment depending on your configuration
• /help - Get help with Mesa commands and configuration options

^{2 files reviewed | 0 comments | Edit Agent Settings}

[hiroTamada]

Great great catch!