docs: update issue draft for inactive product fetches
This commit is contained in:
Shekhar
parent
2d688ae7e8
commit
7c651d3b4e
1 changed files with 23 additions and 96 deletions
119
issues.md
119
issues.md
|
|
@ -1,115 +1,42 @@
|
|||
# Issue Drafts
|
||||
|
||||
## Resolved on `modernize-ui-and-catalog`
|
||||
## Inactive products still trigger backend requests
|
||||
|
||||
### Product detail metadata drift from catalog
|
||||
### Summary
|
||||
|
||||
Status: resolved on this branch.
|
||||
The new `active: false` catalog state is not fully enforced on the product detail page.
|
||||
|
||||
The branch removes the hardcoded `PRODUCT_META` and `RELATED_GROUPS` maps from `frontend/src/pages/ProductDetailPage.tsx` and derives badge, architecture, and related-release data from the structured catalog in `frontend/public/data/products.json`.
|
||||
Inactive products still pass validation and trigger `/skuinfo` requests before the UI shows the discontinued-product panel.
|
||||
|
||||
That closes the earlier mismatch where valid IDs such as `3132`, `3133`, `3263`, `3264`, `3266`, and `3267` rendered incomplete metadata.
|
||||
|
||||
### Unknown product routes triggering backend requests
|
||||
|
||||
Status: resolved on this branch.
|
||||
|
||||
`ProductDetailPage.tsx` now validates `productId` against the local catalog before calling `/skuinfo`. Unknown IDs render a dedicated not-found state instead of immediately hitting the backend and Microsoft endpoints.
|
||||
|
||||
### Hardcoded and inconsistent release counts
|
||||
|
||||
Status: resolved on this branch.
|
||||
|
||||
`HomePage.tsx` and `StatsBar.tsx` now derive the release total from `frontend/public/data/products.json` instead of using stale hardcoded values.
|
||||
|
||||
### Product detail stale build and metadata after navigation
|
||||
|
||||
Status: mostly resolved on this branch.
|
||||
|
||||
The route-loading effect now resets `buildStr`, `productName`, related metadata, and validation state before loading the next product. It also sets explicit title and description values for the not-found path.
|
||||
|
||||
Residual concern:
|
||||
|
||||
- fetch failures are still surfaced as a not-found style state, which is misleading and is tracked below as a separate issue
|
||||
|
||||
### Catalog merge behavior in `msdls_v3.py`
|
||||
|
||||
Status: not treated as a defect.
|
||||
|
||||
`msdls_v3.py` is used manually for periodic catalog maintenance, and `frontend/public/data/products.json` is curated rather than treated as a strict mirror of current upstream availability.
|
||||
|
||||
Because of that, preserving existing entries and metadata during a write is acceptable behavior for this workflow.
|
||||
|
||||
## Open issues
|
||||
|
||||
### Backend session bootstrap timeout was reduced too aggressively
|
||||
|
||||
#### Summary
|
||||
|
||||
`backend/main.go` reduces the HTTP client timeout in `setupSession()` from `10 * time.Second` to `3 * time.Second`.
|
||||
|
||||
#### Affected file
|
||||
|
||||
- `backend/main.go`
|
||||
|
||||
#### Current behavior
|
||||
|
||||
The session bootstrap performs multiple external Microsoft requests. With the shorter timeout, slower or transient network conditions are more likely to force the code into the “proceed anyway” path.
|
||||
|
||||
#### Expected behavior
|
||||
|
||||
Session setup should remain tolerant of ordinary network latency and only give up early if there is a clear reliability or UX reason to do so.
|
||||
|
||||
#### Risk
|
||||
|
||||
This can reduce download-link reliability for users on slower connections or during temporary Microsoft-side latency spikes.
|
||||
|
||||
#### Suggested fix
|
||||
|
||||
- restore the previous timeout, or choose a value based on observed latency rather than guesswork
|
||||
- if faster failure is desired, measure each request separately and log timeout frequency before tightening the limit
|
||||
|
||||
#### Prevention
|
||||
|
||||
- treat external timeout changes as reliability-sensitive behavior changes
|
||||
- record timeout/error rates when tuning values for upstream services
|
||||
- add lightweight observability around bootstrap failures before optimizing timeout thresholds
|
||||
|
||||
### Catalog fetch failures are shown as “Product Not Found”
|
||||
|
||||
#### Summary
|
||||
|
||||
`ProductDetailPage.tsx` maps catalog load failures to a not-found style UI, even when the requested `productId` may be valid.
|
||||
|
||||
#### Affected file
|
||||
### Affected file
|
||||
|
||||
- `frontend/src/pages/ProductDetailPage.tsx`
|
||||
|
||||
#### Current behavior
|
||||
### Current behavior
|
||||
|
||||
If fetching or parsing `/data/products.json` fails, the page runs this fallback behavior:
|
||||
For a catalog entry with `active: false`:
|
||||
|
||||
- `setIsNotFound(true)`
|
||||
- `setProductName('Error Loading Product')`
|
||||
- the page loads the product from `products.json`
|
||||
- `setIsValidated(true)` still runs
|
||||
- the follow-up effect calls `/skuinfo?product_id=...`
|
||||
- the backend and Microsoft endpoints are still hit
|
||||
- only afterward does the page render the `Product Discontinued` state
|
||||
|
||||
The rendered state then tells the user the product does not exist or was removed from the catalog.
|
||||
### Expected behavior
|
||||
|
||||
#### Expected behavior
|
||||
Inactive products should fail fast on the frontend and should not trigger backend or Microsoft API requests.
|
||||
|
||||
Operational failures loading the catalog should render an error state distinct from a true unknown product ID.
|
||||
### Risk
|
||||
|
||||
#### Risk
|
||||
The inactive-product flow still consumes backend capacity and external request budget even though the user cannot download that release.
|
||||
|
||||
Users receive incorrect information, and debugging production issues becomes harder because network or asset problems are disguised as missing products.
|
||||
### Suggested fix
|
||||
|
||||
#### Suggested fix
|
||||
- gate validation on `product.active !== false`
|
||||
- avoid setting `isValidated` for inactive products
|
||||
- ensure the `/skuinfo` effect only runs for active products
|
||||
|
||||
- separate “catalog load failed” from “catalog lookup missed”
|
||||
- render a retryable error state for fetch/parse failures
|
||||
- reserve the not-found state for IDs that were successfully checked against a loaded catalog
|
||||
### Prevention
|
||||
|
||||
#### Prevention
|
||||
|
||||
- model route states explicitly: `loading`, `ready`, `not_found`, and `error`
|
||||
- add a UI test covering catalog fetch failure and asserting that the page does not present a false 404
|
||||
- avoid reusing not-found messaging for transport or asset failures
|
||||
- add a test covering an inactive catalog entry and assert that no backend request is made
|
||||
- model the route state explicitly so `active`, `not_found`, and `error` paths cannot fall through into fetch logic
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue