Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions home/apps/profile/matrix.json
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,7 @@
"description": "Your Matrix profile page",
"runtime": "vite",
"category": "social",
"icon": "profile",
"version": "1.0.0",
"slug": "profile",
"runtimeVersion": "^1.0.0",
Expand Down
3 changes: 2 additions & 1 deletion shell/src/lib/error-boundary-utils.ts
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,8 @@ export function describeUnknownError(error: unknown): string {
if (error instanceof globalThis.Error) return `${error.name}: ${error.message}`;
try {
return String(error);
} catch {
} catch (stringifyError) {
void stringifyError;
return typeof error;
Comment on lines +19 to 21
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Fallback describes the stringify error, not the original error

When String(error) throws and the caught exception is an Error, the function now returns stringifyError.name (e.g. "TypeError") — which names the stringify failure, not the original error argument. A caller reading that string would reasonably assume they're learning about the original error. The previous fallback typeof error was agnostic about both, so the semantic shift is small and this code path is extremely rare in practice, but stringifyError.name could mislead diagnostics downstream if it ever fires.

Prompt To Fix With AI
This is a comment left during a code review.
Path: shell/src/lib/error-boundary-utils.ts
Line: 19-21

Comment:
**Fallback describes the stringify error, not the original error**

When `String(error)` throws and the caught exception is an `Error`, the function now returns `stringifyError.name` (e.g. `"TypeError"`) — which names the *stringify failure*, not the original `error` argument. A caller reading that string would reasonably assume they're learning about the original error. The previous fallback `typeof error` was agnostic about both, so the semantic shift is small and this code path is extremely rare in practice, but `stringifyError.name` could mislead diagnostics downstream if it ever fires.

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

}
}
6 changes: 4 additions & 2 deletions tests/gateway/apps.test.ts
Original file line number Diff line number Diff line change
Expand Up @@ -262,7 +262,7 @@ describe("T711: GET /api/apps", () => {
expect(names).toContain("Timer");
});

it("ships icons for every default app manifest", () => {
it("requires every default app manifest to declare a shipped icon", () => {
const repoRoot = resolve(fileURLToPath(new URL("../..", import.meta.url)));
const appsRoot = join(repoRoot, "home/apps");
const iconsRoot = join(repoRoot, "home/system/icons");
Expand All @@ -287,7 +287,9 @@ describe("T711: GET /api/apps", () => {
continue;
}
const manifest = JSON.parse(readFileSync(fullPath, "utf8")) as { icon?: unknown };
if (typeof manifest.icon === "string" && !shippedIcons.has(manifest.icon)) {
if (typeof manifest.icon !== "string") {
missing.push(`${fullPath.replace(`${repoRoot}/`, "")}: missing icon`);
} else if (!shippedIcons.has(manifest.icon)) {
missing.push(`${fullPath.replace(`${repoRoot}/`, "")}: ${manifest.icon}`);
}
}
Expand Down
15 changes: 15 additions & 0 deletions tests/shell/error-boundary-utils.test.ts
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
import { describe, expect, it } from "vitest";

import { describeUnknownError } from "../../shell/src/lib/error-boundary-utils";

describe("describeUnknownError", () => {
it("falls back to the original value type when string coercion throws", () => {
const errorLikeValue = {
[Symbol.toPrimitive]() {
throw new TypeError("string coercion failed");
},
};

expect(describeUnknownError(errorLikeValue)).toBe("object");
});
});