ENG-54618 Fix concurrent map write bug

[and-bezzir]

Problem

When running multiple upload in sametime from newui parity test I'm getting concurrent map access issue

Concurrent multipart/form-data requests that bind multiple kind=form parameters could crash with a concurrent map write panic in seedFormFromMultipart.

Each Form locator instance resolves its own parameter via Value(), which calls seedFormFromMultipart through a sync.Once. However, multiple Form locator instances share the same *state.Form and *http.Request for a given request. When two locators race, the losing goroutine's sync.Once is a no-op, but the winning goroutine writes to r.form.Values and r.request.Form maps without holding a lock, causing the panic.

A secondary issue existed: calling form.Set(k, vs...) inside seedFormFromMultipart would deadlock if the caller already held the form's RWMutex, because Set re-acquires the same lock internally.

Root Cause

In view/state/kind/locator/form.go, seedFormFromMultipart:

1. No synchronisation — the loop writing to r.form.Values and r.request.Form was completely unguarded.
2. Wrong nil check — len(r.request.Form) == 0 is false for an already-initialised but empty map, so the url.Values{} initialisation was sometimes skipped, leading to a nil-map write.

Fix

• Acquire form.Mutex() (sync.RWMutex) before touching any shared map, and defer its unlock.
• Write to r.form.Values[k] directly instead of calling r.form.Set(), which would attempt to re-lock the same mutex and deadlock.
• Change guard to r.request.Form == nil so the initialisation happens exactly when needed, regardless of map length.
• Cleaned up stale comments that no longer matched the logic.

Changed File

view/state/kind/locator/form.go — 1 file, +10 / −7