Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

A bad list reply crashes or silently empties editor screens

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

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
express, javascript, react
Domain
frontend, testing

Research direction

Start with apiFetch.js and the named callers in Pages.jsx, useTranslationVersions.js, widgetStore.js, Media.jsx, mediaUsageDisplay.js, and themeUpdateStore.js; trace how each handles a successful response with the wrong shape. Add tests for the affected reads and translation list queries, then sweep the other list screens. Done means bad replies show visible load errors, screens remain usable, and empty instead of error cases are recorded under T64; the API caching decision is also made.

Written by the indexing model from the issue text.

Description

bug

A bad reply from the server crashes the Pages screen or empties editor screens. Show a clear "couldn't load" instead.

Seen on 2026-10-02 at 9e98dad7, after upgrading a pre-0.9.10 data folder, in one Firefox session. Some editor requests made during a screen load intermittently resolved to an empty 2xx body, which parseJsonResponse (apiFetch.js) turns into null. The server was not the source: the same requests sent directly (curl, and four concurrent fetch calls from the console) always returned full bodies, and getAllPages responds with an array or a 500. It happened only with the HTTP cache enabled, never in a private window or Firefox Troubleshoot Mode, and stopped after a browser restart, so the trigger is unconfirmed (an extension or the session's cache state). The four affected reads and what each did with null:

  • GET /pages on Pages: loadPages stores it unchecked (Pages.jsx:152); useTranslationVersions runs for every project, single-language too, and entries.map threw, so the error boundary replaced the screen.
  • GET /widgets in the page editor: loadSchemas (widgetStore.js) catches the failure and keeps schemas: {} with error set, but nothing shows the error. Widgets displayed their raw type names, had no settings and the inserter was empty.
  • GET /pages and GET /collections/:type feeding Media's usage labels (Media.jsx loadUsageTitles): buildUsageTitleMap threw on null (its defaults only cover undefined), the bare catch fell back to the global titles, and "Used in" showed raw page:<uuid> / collection:<uuid> sources.
  • GET /themes/update-count (themeUpdateStore.js): result.count threw and was logged; the badge silently stayed at its previous value.

Any non-array or non-object 2xx body (e.g. an HTML string) fails the same way. Other callers to check: CollectionItems.jsx (items) and EditorTopBar.jsx (allPages) feed useTranslationVersions from server lists, and CollectionItemForm.jsx builds its entries from the item's translation group. Other editor list screens (menus, media, collections and similar) have not been swept. Embedding apps mount these screens and inherit the behaviour.

Treat a reply of the wrong shape as a load failure, and show it: the existing load-error toast for lists, and a visible "couldn't load widgets" state in the editor. Not an empty list, which would read as deleted content. Then sweep the remaining list screens once: fix crashes and silent failures here, and hand cases that show an empty list instead of an error to T64. Separately consider Cache-Control: no-store on editor API JSON replies: they are per-request data, and Express currently sends ETags with no cache directive, so browsers revalidate and reuse stored copies.

Done when: Each read above, and each list query feeding useTranslationVersions, shows a visible load error on a bad reply, the screen stays usable, and tests cover it. The sweep of other list screens is done, with any empty-instead-of-error cases recorded under T64. The API caching decision is made.

Start: Pages.jsx, useTranslationVersions.js, widgetStore.js, Media.jsx, mediaUsageDisplay.js, themeUpdateStore.js, apiFetch.js. Source: 2026-10-02 upgrade walkthrough.

Dominant language
JavaScript
Stars
162
Forks
6
Avg merge
12h 55m
Merged PRs (30d)
2

Getting set up

  • Ships a Dockerfile or Docker Compose file
  • No pull request template
  • No contributing guide

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 tsiger/widgetizer

All issues in tsiger/widgetizer

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.