Partial reload `only` option behavior with lazy, deferred, and shared props

Short answer

The only option filters which page props the server evaluates and returns for that single request, but it does not strip shared middleware data: shared props are resolved by middleware outside the page-prop closure and are merged into the response regardless of the filter. Lazy and deferred props that are omitted from only are simply not re-evaluated — the client keeps whatever value (or absence of value) it already had. Nothing is reset to undefined as a side effect of being left out of only.

Shared middleware props

Shared data (registered via HandleInertiaRequests::share() in Laravel, or the equivalent in other adapters) is merged into every Inertia response after page props are resolved. Because the merge happens outside the per-prop filtering step, shared keys survive an only partial reload. This is the likely explanation if you are seeing "extra" keys in a filtered payload — it is expected behavior, not a leak in the filter. The caveat is that the exact boundary between "filtered page props" and "always-merged shared props" has shifted between Inertia 1 and Inertia 2, so treat any absolute claim here as version-sensitive and verify against your installed release.

Lazy props omitted from only

A lazy prop (a closure wrapped with Inertia::lazy() or an optional closure in v2) is only evaluated when explicitly requested. If it is omitted from only:

• The server does not run the closure, so no fresh value is produced.
• The client does not delete the prop. If it was loaded by an earlier request, the previous value is retained in the page object; if it was never loaded, it stays absent.

So "omitted" means "unchanged," not "cleared."

Deferred props and the automatic reload

Deferred props (Inertia 2's Inertia::defer()) work by the client issuing a follow-up partial reload for the deferred group immediately after the initial render. That automatic reload is driven by the deferred group definition, not by any only list you pass elsewhere. If you fire your own partial reload with only: ['somethingElse'], the deferred prop's scheduled reload still occurs independently; conversely, your filtered request will not include the deferred prop's value. The practical effect: a deferred prop becomes available on the page once its own automatic reload completes, and your unrelated only requests neither block it nor deliver it early.

How to verify on your version

Because the shared-prop interaction differs between major versions, confirm empirically rather than trusting documentation summaries:

1. Open the browser devtools Network tab and trigger the partial reload.
2. Inspect the JSON response (requests with the X-Inertia header return JSON) and check whether shared keys and omitted lazy keys appear.
3. Record a lazy prop's client-side value before and after an only reload that excludes it — it should be byte-identical.
4. Watch for the automatic second request after initial render to confirm deferred groups fire regardless of your manual only calls.

If you are pinned to Inertia 1, double-check the shared-middleware behavior specifically — that is the point most likely to differ from the description above. If you share your adapter and version, the answer can be narrowed further.