[2.0 / next] Regression (#4456): an Errored mounted with an error stays on its fallback after a keyed projection's answer lands
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 65/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- javascript, typescript
Hướng nghiên cứu
Start with the reproduction in packages/web/test and run it for both keyed and unkeyed cases. Trace how the keyed createProjection interacts with Errored when the boundary mounts in the same change as the error. Done means the later answer replaces the fallback in both cases, matching the expected appleapricot output.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Regression. This is broken at next ecf30116 and was fine at e21c2aef. Bisecting puts the change at 749b0d77, #4456 ("a staged error reaches the memos and derived stores that derive from it").
What happens. A <Show> mounts an <Errored> in the same change that its content fails. Inside is a keyed createProjection over a memo, under <Loading>. The memo then re-asks and the new answer lands, but the boundary stays on its fallback. The same thing over the memo directly (no projection) replaces the error as expected.
Where we found it. ReactiveScript's conformance suite, scenario S-ai2-search. A search pane mounts when the query becomes non-empty, a one-character query throws "too short", and typing a second character fetches. The results never replace the hint.
Repro (packages/web/test)
/**
* @jsxImportSource @solidjs/web
* @vitest-environment jsdom
*/
import { test } from "vitest";
import { Show, Errored, Loading, For, createSignal, createMemo, createProjection, flush } from "solid-js";
import { render } from "../src/index.js";
const tick = async () => { for (let i = 0; i < 4; i++) { await new Promise(r => setTimeout(r, 0)); flush(); } };
for (const keyed of [true, false])
test(`an answer replaces the error a boundary was born with (keyed=${keyed})`, async () => {
const asks: { key: string; res: (v: any) => void }[] = [];
const ask = (key: string) => new Promise<any>(res => asks.push({ key, res }));
const land = async (key: string, v: any) => { for (const a of asks.filter(a => a.key === key)) { asks.splice(asks.indexOf(a), 1); a.res(v); } await tick(); };
const container = document.body.appendChild(document.createElement("div"));
const frames: string[] = []; const snap = (l: string) => frames.push(`${l}: ${container.textContent}`);
let setQ!: (q: string) => void;
render(() => {
const [q, sq] = createSignal(""); setQ = sq;
const src = createMemo(() => { const s = q(); if (s === "") return []; if (s.length < 2) throw new Error("too short"); return ask(`search:${s}`); });
const results: () => any[] = keyed ? (() => { const p = createProjection(() => src() as any, [] as any, { key: "id" } as any); return () => p as any; })() : (src as any);
return <Show when={q() !== ""}>
<Errored fallback={(e: any) => <p>{e().message}</p>}>
<Loading fallback={<p>loading</p>}>
<For each={results()}>{(r: any) => <i>{r.name}</i>}</For>
</Loading>
</Errored>
</Show>;
}, container);
await tick(); snap("mount");
setQ("a"); await tick(); snap("query a");
setQ("ap"); await tick(); snap("query ap");
await land("search:ap", [{ id: 1, name: "apple" }, { id: 2, name: "apricot" }]); snap("answer");
console.log(`keyed=${keyed}\n` + frames.join("\n"));
container.remove();
});
Output at ecf30116
keyed=true
mount:
query a: too short
query ap: too short
answer: too short <- stays on the error
keyed=false
...
answer: appleapricot
At e21c2aef (the parent of 749b0d77), both cases end with answer: appleapricot.
What it needs
- The boundary has to mount in the same change as the error. Without the
<Show>, so the boundary exists before the query changes, the answer replaces the error. - The read has to go through the keyed projection. Reading the memo directly is fine.
Expected
answer: appleapricot in both cases: a value replaces a shown error (D-41).
- Ngôn ngữ chính
- TypeScript
- Star
- 36.2k
- Fork
- 1.1k
- Merge trung bình
- 10 giờ 39 phút
- Pull request đã merge (30 ngày)
- 500
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của solidjs/solid
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 55/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
Maintainer thường phản hồi trong vòng 1 ngày
-
[2.0 / next] Optimistic todo list with an "N left" memo loops forever when a toggle's save landsĐang mở
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 15/100
Maintainer thường phản hồi trong vòng 1 ngày
-
[2.0 / next] createOptimisticStore: add, delete, add with saves pending hands <For> an undefined rowĐang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 25/100
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của solidjs/solid
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
ready-for-agent
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
LucasSantana-Dev/Lucky#2951 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
danielmiessler/LifeOS#2567 ·
Maintainer thường phản hồi trong vòng 9 ngày
-
refactor(react-pi): classify base64 images with core's parseBase64Có thể đã có người làm @jimmyallinai đã nhận hôm nay. Đang mởmaintenance
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
assistant-ui/assistant-ui#10293 · 2 bình luận · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
brijeshb42/monaco-vim#175 ·