verify's reload check reads a form refused for a duplicate as a saved value that came back different

Open
  • Is something wrong?
#697 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
Half a day
Newbie friendliness
70/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
bun, javascript
Domain
devtools, testing-qa

Research direction

Start at typedFields in scripts/verify.mjs (around line 223 on 65065d29a) and read the comment that already distinguishes a refused form's draft from a saved value; the kept-value test compares field text against state and resources only, so a duplicate-refusal draft matches the record it duplicates. Reproduce by running bun exact.mjs pattern list-detail with the contract in the issue, then bun exact.mjs verify web to see the single reload finding. Done means that repro reports no finding, and a verify-side test covers a refused duplicate draft.

Written by the indexing model from the issue text.

Description

What happened

A test that ends on a form the app refused because its value is already taken passes, and then
verify web reports a lost saved value. With the list-detail pattern, after adding "Milk" and
then trying to add "Milk" again:

tests: 1 passed, 0 failed
reload 1 test end: 1 finding
  reload   /add a saved value came back different: the field "add-title" showed "Milk", which the app holds, and shows ""; a reload must bring back what was saved ("a second item with a title already …")

"Milk" in that field was never saved. It is the draft the app just refused, and the sheet says
so (add-error: "There’s already an item called Milk. Choose another title."). The app holds
"Milk" only as the first item's title, which the reload keeps.

In scripts/verify.mjs (typedFields, line 223 on main at 65065d29a), a typed field shows a
kept value when its text is among what the app's state and resources hold both before and after
the reload. A refusal for a duplicate always passes that test, because the record it duplicates
holds the same text. So the draft is compared as a saved value, and the field the reload empties
is a finding. The function's comment names "a form the app refused with its error" as a draft, so
this looks unintended. We first hit it with a shop name refused as already taken.

What I expected: no finding. The field held a draft, which a reload is not expected to bring
back.

Host

Web

Smallest app that shows it

bun exact.mjs pattern list-detail, unchanged, with this app.test.contract, then
bun exact.mjs verify web:

test "a second item with a title already taken is refused"
  clock data
  tap "empty-add"
  clock settle
  type "add-title" "Milk"
  tap "add-save"
  clock data
  clock settle
  expect tree has "item-1"
  tap "add-item"
  clock settle
  type "add-title" "Milk"
  tap "add-save"
  clock data
  clock settle
  expect text "add-error" == "There’s already an item called Milk. Choose another title."
Exact commit

65065d29a

Dominant language
Rust
Stars
2.8k
Forks
62
Avg merge
2h 48m
Merged PRs (30d)
126

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from expo/exact

All issues in expo/exact

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.