Describe the problem
When a client requests a refresh for a query as part of a single-flight
mutation, and the command never calls requested(X) for that query, the
request is silently dropped. Nothing is logged, nothing is returned, and
the query simply doesn't refresh.
This is almost always a bug rather than an intentional choice: the
developer believes they wired up single-flight refreshing and instead got
a silent no-op. Because there is no signal at all, diagnosing it means
working backwards from "the UI didn't update" through the entire
request/response path before landing on the one missing call.
Describe the proposed solution
Emit a DEV-mode warning when a requested refresh is not consumed by the
command, naming the specific query that was dropped. For example:
[remote functions] Refresh was requested for getItems but the command
updateItem never called requested(getItems). The refresh was dropped.
Additionally, include the set of dropped keys in the response payload so
the client can warn with the actual call site attached — that turns a
server-side hint into an actionable stack trace pointing at the component
that asked for the refresh.
Alternatives considered
-
Throwing instead of warning: too aggressive. There are legitimate cases
where a command conditionally skips a refresh, and a hard error would
break them.
-
Auto-refreshing any query the client requested: changes the semantics of
single-flight mutations and removes the command's control over what gets
revalidated. Also risks over-fetching.
-
Documentation only: doesn't help, since the failure mode is silent and
the developer has no reason to suspect this particular call is missing.
-
Client-side timeout/staleness detection: too indirect, and can't
distinguish a dropped refresh from a query that legitimately returned
unchanged data.
Importance
would make my life easier
Additional Information
A warning here would have collapsed a multi-hour investigation into about
one minute. The failure is invisible by design — the request succeeds, the
command succeeds, the response is well-formed, and only the refresh is
missing.
Scoping this to DEV mode keeps production payloads and logs unaffected.
Describe the problem
When a client requests a refresh for a query as part of a single-flight
mutation, and the command never calls
requested(X)for that query, therequest is silently dropped. Nothing is logged, nothing is returned, and
the query simply doesn't refresh.
This is almost always a bug rather than an intentional choice: the
developer believes they wired up single-flight refreshing and instead got
a silent no-op. Because there is no signal at all, diagnosing it means
working backwards from "the UI didn't update" through the entire
request/response path before landing on the one missing call.
Describe the proposed solution
Emit a DEV-mode warning when a requested refresh is not consumed by the
command, naming the specific query that was dropped. For example:
[remote functions] Refresh was requested for
getItemsbut the commandupdateItemnever calledrequested(getItems). The refresh was dropped.Additionally, include the set of dropped keys in the response payload so
the client can warn with the actual call site attached — that turns a
server-side hint into an actionable stack trace pointing at the component
that asked for the refresh.
Alternatives considered
Throwing instead of warning: too aggressive. There are legitimate cases
where a command conditionally skips a refresh, and a hard error would
break them.
Auto-refreshing any query the client requested: changes the semantics of
single-flight mutations and removes the command's control over what gets
revalidated. Also risks over-fetching.
Documentation only: doesn't help, since the failure mode is silent and
the developer has no reason to suspect this particular call is missing.
Client-side timeout/staleness detection: too indirect, and can't
distinguish a dropped refresh from a query that legitimately returned
unchanged data.
Importance
would make my life easier
Additional Information
A warning here would have collapsed a multi-hour investigation into about
one minute. The failure is invisible by design — the request succeeds, the
command succeeds, the response is well-formed, and only the refresh is
missing.
Scoping this to DEV mode keeps production payloads and logs unaffected.