fix(admin): a published item does not appear in Inventory until the page is reloaded #327

New Issue

2026-09-09T11:58:56-05:00

bermudalamb commented

2026-09-09 11:58:56 -05:00

Reported from QA: two items published from the Review queue did not appear in the Inventory tab.

Nothing is wrong with publishing. The items are published, the rows are correct, and the API returns them. The Inventory tab is showing a list it fetched earlier and never refreshed.

Mechanism

Admin.tsx renders its tabs with antd's items prop and does not set destroyInactiveTabPane, so a pane stays mounted once rendered. defaultActiveKey="inventory" means Inventory mounts at page load whether or not you look at it.

Inventory fetches in exactly one place:

useEffect(() => { void load(filters); }, [load, filters]);

load is memoised on [filters], so that effect runs on mount, and when the filters change. Nothing else.

So the sequence is:

Open the admin — Inventory mounts and fetches.
Switch to Review queue, publish two items.
Switch back to Inventory — the component was never unmounted, no dependency changed, no fetch happens.

The list is whatever it was at page load. A browser reload shows the items, which is what makes this read as "publishing is broken" rather than "the table is stale".

This was already half-known

Inventory has a comment on the other fetch:

The item form needs the current category tree and tag list; both change from the sibling tabs, so they're refetched whenever the modal opens.

The staleness caused by sibling tabs was recognised and handled — but only for the dropdowns inside the item form, not for the item list itself. DraftQueue sidesteps it with an explicit Refresh button; Inventory has none.

Proposed fix

Track the active tab in Admin and tell Inventory when it is the visible one, so it refetches on becoming active.

Rejected: destroyInactiveTabPane on the Tabs. It would fix this by remounting, but it discards every tab's state on every switch — filters, scroll position, a half-filled form — and refetches all of them repeatedly. That is a much larger behavioural change than the bug warrants.

Scope

This issue covers Inventory, which is what was reported and where it costs the most — it is the tab you check to confirm a publish worked.

The same pattern almost certainly affects Categories, Tags, Upload links and Customers, which are all mounted-once children of the same Tabs and all changeable from elsewhere. Worth confirming and fixing together or separately, but not silently assumed to be fine.

Done when

Publishing from the Review queue and switching to Inventory shows the item without a page reload, covered by an end-to-end test that fails against the current behaviour.

Reported from QA: two items published from the Review queue did not appear in the Inventory tab. **Nothing is wrong with publishing.** The items are published, the rows are correct, and the API returns them. The Inventory tab is showing a list it fetched earlier and never refreshed. ## Mechanism `Admin.tsx` renders its tabs with antd's `items` prop and **does not set `destroyInactiveTabPane`**, so a pane stays mounted once rendered. `defaultActiveKey="inventory"` means `Inventory` mounts at page load whether or not you look at it. `Inventory` fetches in exactly one place: ```js useEffect(() => { void load(filters); }, [load, filters]); ``` `load` is memoised on `[filters]`, so that effect runs **on mount, and when the filters change. Nothing else.** So the sequence is: 1. Open the admin — Inventory mounts and fetches. 2. Switch to Review queue, publish two items. 3. Switch back to Inventory — the component was never unmounted, no dependency changed, no fetch happens. The list is whatever it was at page load. A browser reload shows the items, which is what makes this read as "publishing is broken" rather than "the table is stale". ## This was already half-known `Inventory` has a comment on the *other* fetch: > The item form needs the current category tree and tag list; both change from the sibling tabs, so they're refetched whenever the modal opens. The staleness caused by sibling tabs was recognised and handled — but only for the dropdowns inside the item form, not for the item list itself. `DraftQueue` sidesteps it with an explicit **Refresh** button; Inventory has none. ## Proposed fix Track the active tab in `Admin` and tell `Inventory` when it is the visible one, so it refetches on becoming active. Rejected: `destroyInactiveTabPane` on the Tabs. It would fix this by remounting, but it discards every tab's state on every switch — filters, scroll position, a half-filled form — and refetches all of them repeatedly. That is a much larger behavioural change than the bug warrants. ## Scope This issue covers Inventory, which is what was reported and where it costs the most — it is the tab you check to confirm a publish worked. **The same pattern almost certainly affects Categories, Tags, Upload links and Customers**, which are all mounted-once children of the same Tabs and all changeable from elsewhere. Worth confirming and fixing together or separately, but not silently assumed to be fine. ## Done when Publishing from the Review queue and switching to Inventory shows the item without a page reload, covered by an end-to-end test that fails against the current behaviour.

bermudalamb referenced this issue from a commit

2026-09-09 12:05:18 -05:00

fix(admin): refetch Inventory when its tab becomes visible (#327)

bermudalamb referenced a pull request that will close this issue

2026-09-09 12:05:35 -05:00

fix(admin): refetch Inventory when its tab becomes visible (#327) #328

bermudalamb closed this issue

2026-09-09 13:32:40 -05:00

bermudalamb referenced this issue from a commit

2026-09-09 13:32:42 -05:00

fix(admin): refetch Inventory when its tab becomes visible (#327)

bermudalamb referenced this issue from a commit