Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

app_test.go (1)

2128-2132: 💤 Low value

Timing-based assertion could be flaky.

The 20ms wait to verify render hasn't entered is susceptible to flakiness under CI load. Consider increasing this timeout or adding a more deterministic synchronization mechanism if flakiness is observed.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app_test.go` around lines 2128 - 2132, The timing-based assertion using a
20ms timeout on select (checking view.renderEntered) is flaky; increase the
timeout (e.g., to 200ms) or, better, replace the ad-hoc timing with
deterministic synchronization: have the test control when ReloadViews.Load
proceeds (for example by adding a blocking channel or sync.WaitGroup used by the
mocked ReloadViews.Load) and then assert that view.renderEntered remains empty
until you release that blocker, referencing the test's select that reads
view.renderEntered and the ReloadViews.Load mock to implement the deterministic
block/unblock.

app_test.go:2370

• This mounted-app regression also uses app.Test while the reload is blocked. During app.Test, startupProcess locks mounted sub-apps via ensureAutoHeadRoutes, so the render request can be waiting on the reloading sub-app's app.mutex rather than on the shared view-engine lock. Pre-start the mounted app and exercise the request handler without the test startup path so the test actually fails when the render RLock is absent.

	go func() {
		_, err := app.Test(httptest.NewRequest(MethodGet, "/b/render", http.NoBody))
		renderDone <- err

mount.go (1)

48-49: ⚖️ Poor tradeoff

setViewsLockStore called without synchronization.

setViewsLockStore iterates subApp.mountFields.appList without holding any mutex. If subApp is being modified concurrently (unlikely during typical app setup), the map iteration could cause a runtime panic.

The read of app.viewsLockStore is also unsynchronized.

In practice, mount operations occur during single-threaded app setup before Listen(), so this is unlikely to cause issues. Flagging for awareness if concurrent mount patterns are ever supported.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@mount.go` around lines 48 - 49, The call to
subApp.setViewsLockStore(app.viewsLockStore) accesses subApp.mountFields.appList
and reads app.viewsLockStore without synchronization; update setViewsLockStore
(and any callers) to acquire the appropriate mutex(es) before iterating
subApp.mountFields.appList and before reading app.viewsLockStore to prevent
concurrent map access panics. Specifically, inside setViewsLockStore (or a
wrapper) lock subApp.mountFields' mutex (e.g., mountFields.mu) while iterating
appList, and ensure any read of app.viewsLockStore is performed under app's
read-lock or by copying the reference under app's lock before releasing it.
Ensure locks are held only for the minimal duration to avoid contention.

app.go (1)

118-161: 💤 Low value

Edge case in keying logic for non-comparable struct Views.

If a Views implementation is a non-comparable struct (e.g., contains a slice or map field) but is not itself a pointer/chan/func/map/slice, the key falls through to the default case and only typ is populated. This means all instances of such a type would share a single lock.

This is still safe (no data races), but could cause unnecessary serialization when different view engine instances of the same non-comparable struct type are used.

In practice, most Views implementations are pointers, so this edge case is unlikely to occur. Flagging for awareness.

Possible fix: use unsafe pointer for any addressable non-comparable value

 	} else {
 		switch viewValue.Kind() {
 		case reflect.Pointer, reflect.Chan, reflect.Func, reflect.Map, reflect.Slice, reflect.UnsafePointer:
 			key.ptr = viewValue.Pointer()
-		default:
+		default:
+			if viewValue.CanAddr() {
+				key.ptr = viewValue.Addr().Pointer()
+			}
 		}
 	}

Note: Interface values passed directly are typically not addressable, so this may not fully resolve the edge case. Consider documenting this limitation.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app.go` around lines 118 - 161, The keying logic in viewsLockStore.get can
collapse distinct non-comparable struct instances of the same type into one lock
because for non-comparable values that are not pointer/chan/func/map/slice it
only uses typ; fix by populating key.ptr for addressable non-comparable values:
in viewsLockStore.get (function get, types viewsLockKey, viewsLockStore,
variable viewValue/Views) check viewValue.CanAddr() and if true use
viewValue.UnsafeAddr() (or create an addressable copy with
reflect.New(viewValue.Type()) and set it) to set key.ptr so different instances
get different keys; leave the existing pointer/chan/func/map/slice handling and
document the remaining limitation for non-addressable interface values.

app.go (1)

141-148: 💤 Low value

Non-pointer, non-comparable Views instances of the same type will share a single lock.

When viewValue.Kind() is not pointer-like and viewValue.Type().Comparable() is false, neither key.ptr nor key.view is set. This causes all distinct instances of the same non-comparable value type to share one lock, which may lead to unintended cross-instance blocking.

This is an edge case since most Views implementations are pointers, but consider adding a comment documenting this limitation or handling it explicitly (e.g., by storing the address of the interface data if possible).

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app.go` around lines 141 - 148, The current switch in app.go leaves key.ptr
and key.view unset for non-pointer, non-comparable Views values causing distinct
instances to share a lock; update the logic in the switch handling for
viewValue.Kind() (and the code that constructs the lock key) to explicitly
handle this case: if viewValue is not pointer-like and not Comparable(), obtain
a unique identifier for the concrete instance (for example use
reflect.Value.CanAddr()/Addr() or fallback to using unsafe.Pointer to the
interface data) and store that address into key.ptr (or another dedicated key
field) so each distinct non-comparable value gets its own lock; alternatively
add a clear comment near viewValue, key.ptr and key.view documenting the
limitation if you decide not to change behavior.