From acf9ff94af1828c63f61c2dc383e62a6794e5532 Mon Sep 17 00:00:00 2001 From: cliffhall Date: Sun, 23 Aug 2026 22:20:17 -0400 Subject: [PATCH] docs(web): state that the listing lookup is best-effort It does not distinguish "no entry for this URI" from "the list has not arrived yet"; both yield no hints, which is what a host with no listing carrier gets anyway. Say so at the lookup, with why blocking on list readiness is worse: for a server advertising no `resources` capability, or one whose list errored, that request never resolves, so the app would never render at all. Signed-off-by: cliffhall --- clients/web/src/App.tsx | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/clients/web/src/App.tsx b/clients/web/src/App.tsx index 59201890..4690a650 100644 --- a/clients/web/src/App.tsx +++ b/clients/web/src/App.tsx @@ -792,6 +792,13 @@ function App() { // derived further down this component, and the factories only read it inside // an async sandboxready handler, long after any render that produced it. const listedResourcesRef = useRef([]); + // Best-effort by construction: this reads the list as it stands when the app + // opens, and does not distinguish "no entry for this URI" from "the list + // hasn't arrived yet". Both yield no hints, which is the same outcome as + // having no listing carrier at all. Blocking the render on list readiness + // instead would mean waiting on a request that, for a server advertising no + // `resources` capability or whose list errored, never resolves — trading a + // missing default for an app that never renders. const getListedResourceMeta = useCallback( (uri: string) => listedResourcesRef.current.find((r) => r.uri === uri)?._meta,