ShareModal discards the host's visibility-change error text (double .error hop on a string)
@MAYANKSHARMA01010 ci sta già lavorando.
Dal 24/8/2026.
Valutazione
Questa issue non è ancora stata valutata.
Descrizione
Summary
ShareModal's visibility-change notification always renders as a bare "Failed to update visibility. " with no detail, because it dereferences .error twice on a value its own prop type declares as a plain string.
Where
ShareModal, in the published @sistent/sistent@0.22.0 bundle (dist/index.mjs):
const B = `Failed to update visibility. ${q?.error?.error || ""}`;
q.error
? d({ message: B, event_type: "error" })
: d({ message: N, event_type: "success" });
q here is the awaited result of the host-supplied handleUpdateVisibility prop.
Why it is wrong
ShareModalProps types that prop as:
handleUpdateVisibility: (value: string) => Promise<{ error: string }>;
So q.error is a string. The branch test q.error is correct, but the message interpolates q.error.error - a .error lookup on a string - which is always undefined, so || "" collapses it to the empty string. Every message a host composes is discarded and the user is told only that something failed, never what.
The adjacent revoke path is fine, since there the value genuinely is an RTK result:
{ error: N?.error?.error }
That is likely where the extra hop was copied from.
Impact
Hosts have no way to surface a reason for a failed visibility change. In Kanvas (layer5labs/meshery-extensions) we normalize RTK's several error shapes into the documented { error: string } and return a specific message for unsupported resource kinds; none of it can reach the user.
This is in the same silent-failure family as the payload casing bug fixed in #1786 - the failure is now correctly detected (a 4xx/5xx no longer reports as success), but the explanation is dropped on the floor.
Suggested fix
const B = `Failed to update visibility. ${q?.error || ""}`;
If the double hop is there to tolerate hosts that return an RTK result rather than the documented shape, normalizing once would be clearer than an optional-chained guess:
const detail = typeof q?.error === "string" ? q.error : (q?.error?.error ?? "");
Reproduce
Pass a handleUpdateVisibility that resolves to { error: "visibility rejected" } and trigger a visibility change. Expected: the reason appears in the error notification. Actual: "Failed to update visibility. ".
Environment
@sistent/sistent0.22.0 (verified against the published npm artifact, not a local build)
- Lingua principale
- TypeScript
- Stelle
- 137
- Fork
- 239
- Merge medio
- 4g 14h
- PR unite (30g)
- 5
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di layer5io/sistent
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
-
component/ui help wanted kind/enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
-
ESM build is not loadable by Node: extensionless 'lodash/debounce' specifier in dist/index.mjs Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
-
kind/bug
Tutte le issue di layer5io/sistent
Issue simili
-
bug(cli): hapi doctor inline-media prints a fabricated B:\ helper-script path in packaged installs Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
-
Crush Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 85/100
catppuccin/catppuccin#3125 ·
-
Add a SECURITY.md Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
ElementsProject/cln-application#167 · 1 commento · 1 reazione ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
Quantco/pnpm-licenses#17 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100