- Shipped
- September 6, 2026 at 2:22 AM UTC
- Author
- Kamo
- Commit
- c7724cb
The tab was invisible to every team member in every organization, including one looking at an open posting. Not a rights problem, though it was shaped exactly like one: **************** had no Next route behind it. The gate added in f24039c0 hangs on memberCareersApi.openings(). Next answers an unrouted path with its own 404 HTML, read<T> throws on that, and the caller's catch — which exists so a failed count withholds the tab rather than opening one onto an error — swallowed it. careerOpenings stayed null, (null ?? 0) > 0 stayed false, and the tab never rendered. Every other layer was already right: the endpoint answers, APIService forwards it, CareersAccess.requireView admits a team member, and against the live cluster the whole chain now returns {"accepting":1}. /api/docs is where this keeps happening. Most feature areas proxy through an optional catch-all, so a path under them routes whether or not anybody remembered it; /api/docs has none, so each of the sixteen careers paths is a file. The documents UI lost a release to the identical bug — see docsApiRoutesExist.test.ts, written for a form-fillable route that was never created. applied-prompt/dismiss was missing too, and had been failing silently in the same way: CareersTab fires it as the apply dialog closes and discards the result, so the prompt a member has already spent simply came back, forever. It is one line of the same omission and is fixed with it. The guard is the point of the change. careersApiRoutesExist.test.ts resolves the HR and ME prefix constants and checks every URL the client builds, because the documents check cannot see this file — it matches literals beginning /api/docs, and careersApi.ts has none. It fails on both routes before this commit.