Do nested Livewire components inherit the parent's #[Locked] attribute or acquire independent locks?

Direct answer

A parent's #[Locked] attribute does not implicitly serialize updates to its nested child components. Locking in Livewire v3 is scoped to the individual component instance: each component that declares #[Locked] acquires its own mutex, keyed off that component's ID, for the duration of its own update request. A child rendered via @livewire('child', key($id)) is an independent unit of state and execution; it must declare #[Locked] itself to ensure its own updates are serialized.

Likely explanation vs. confirmed facts

The architectural fact is that Livewire processes component updates as separate requests (or separately addressed updates), and the lock key is derived from the component's own identity—following the livewire:component:{id}:lock pattern. Because the key is per-ID, there is no mechanism for a parent's mutex to cover a child with a different ID. There is no evidence in the framework design of tree-wide lock inheritance.

The part to treat as likely but requiring version-specific verification is the exact acquisition point in HandleComponentRequests and whether any edge case (such as a child update bundled into a parent's request payload) shares the parent's critical section. Livewire v3 internals have evolved across minor releases; treat per-component locking as the current implementation rather than a permanent contractual guarantee.

Impact on correctness and latency

• Correctness: Concurrent updates to a parent and an unlocked child can interleave. If the child reads state derived from parent-passed properties, add #[Locked] to the child or avoid sharing mutable state across the boundary by treating the child as the owner of its internal state.
• Latency: A single lock does not serialize the entire tree by default. However, blanket-applying #[Locked] to every component in a deep tree can increase tail latency, as concurrent child updates will serialize per component. Apply it only where concurrent mutation of the same component's state is possible.

How to verify on your version

1. Mark only the parent #[Locked], then fire two rapid updates at a child (e.g., double-click a button triggering a slow server-side action with an artificial sleep(2)).
2. In the browser's network tab, check whether the two child requests overlap in time (parallel indicates independent locking) or if the second waits for the first (serialized).
3. Repeat with #[Locked] on the child. The second request should now queue behind the first.
4. For ground truth, inspect the lock-key generation in your vendor/livewire/livewire source—search for mutex/cache-lock logic in the request-handling pipeline to confirm the key incorporates the component ID.

One caveat: if child updates are triggered by events the child dispatches that the parent listens to, the parent's re-render is a separate concern. Event-driven re-renders do not transfer locks in either direction. To provide a more precise source-level reference, please provide your exact Livewire version (e.g., 3.x minor).