Repository navigation
GET /getRelatedOKH ignores the keywords query param entirely #107
Description
What's happening
GET /api/getRelatedOKH (packages/back-end/src/functions/httpFunctions.ts:151) is registered with no {keywords} path template — it's just the bare route name getRelatedOKH in the routeFunctions map. The handler reads the keyword from request.params.keywords, which only populates from a path template, so it's always undefined.
const keywords: string[] = normalizeKeywords(decodeURIComponent(request.params.keywords))decodeURIComponent(undefined) coerces to the literal string "undefined", so the effective keyword filter is always exactly ["undefined"] — the query string (?keywords=...) is never actually read, regardless of what a client sends.
Impact
The "related items" feature on the product detail page (RelatedItems.vue) always gets an effectively-empty/meaningless keyword filter, so results are unrelated to the product being viewed (or empty, coincidentally, since no current OKH file is tagged "undefined").
Evidence
- Confirmed live:
curl .../getRelatedOKH?keywords=cookiesvscurl .../getRelatedOKH?keywords=anything-elsereturn identical results. - Captured as a regression baseline (asserts the two-different-queries-return-identical-results property) in
packages/back-end/test/api.test.ts.
Likely fix
Register the route with a path template (e.g. getRelatedOKH/{keywords}) matching how the front end actually calls it, or read from request.query.get("keywords") instead of request.params.keywords if the intent is a query-string param (which is how RelatedItems.vue currently sends it).
Tracked as a known issue in dev-docs/CLEANUP_PLAN.md / AGENT.md.
Activity
Link tracked follow-up issues in CLEANUP_PLAN.md
NimeshaKahingala commentedon Sep 13, 2026
Correction — closing as invalid
This issue was based on a flawed analysis. The reasoning was: "the route has no
{keywords}path template, sorequest.params.keywordsmust beundefined, so the query string is never read." That reasoning doesn't hold for this Azure Functions host.Empirically verified:
request.paramsis populated from the invocation's RPC binding data sent by the Azure Functions host, and that binding data flattens query-string values in even without a matching route template segment. So?keywords=<value>genuinely reachesrequest.params.keywords, and the endpoint's keyword matching (hasOverlapKeywords/normalizeKeywords— exact-token, case-insensitive) actually works correctly:The original "always returns empty" observation was real but coincidental — every keyword tried in that investigation ("cookies", "undefined", random strings) simply didn't exact-match any real file's keyword field, which looked like "ignores the param entirely" but wasn't.
packages/back-end/test/api.test.tsanddev-docs/CLEANUP_PLAN.md/TESTING.md/AGENT.mdhave been corrected accordingly in PR #105.Apologies for the noise — closing.
Retract a false getRelatedOKH bug claim; fix E2E timeout and other re…