Summary
#2378 found the Formations queue returning 3 rows instead of 126 because foundation scoping matches a project's immediate parent rather than its ancestry, and the LF root's direct children are 3 of 126.
#2380 fixed that one endpoint. While doing so it found the same shape on five others sharing ProjectService.getFoundationProjectUids:
/api/committees/my-committees/api/user/meetings/api/user/past-meetings/api/user/latest-past-meetings- the public foundation directory
Several also lack the param validation #2369 added for foundation_uid on the queue.
Why it matters beyond the formations queue
The failure is silent in exactly the same way. A foundation with intermediate projects under it under-reports, and nothing on the page says so — the user sees a shorter list and has no reason to doubt it.
The formations queue made it obvious only because the root is the extreme case: 123 of 126 hidden. Elsewhere the gap will be smaller and therefore harder to notice, which does not make it less wrong. Production has 33 distinct parents across 126 formations, so intermediate nesting is the norm, not an edge case.
/api/committees/my-committees is worth looking at first: #2369 cited it as the naming precedent for the foundation_uid param, so it is the endpoint most likely to share the queue's exact assumptions.
What is not being claimed
I have not measured the under-report on any of these five. #2380 identified them by shared code path, not by observation. Someone should check each against production before deciding how urgent it is — the shape is the same but the impact depends on how many rows sit under intermediate parents in each case, and for some of them the answer may be none.
That measurement is the first task here, not the fix.
Relationship to the other two
If #2368 lands, most of this dissolves. If it does not land soon, each of these five needs its own decision, and the root special-case is the pattern to copy.
Worth deciding that at the top rather than per-endpoint — five copies of a workaround is how a workaround becomes the architecture.
Also
While in here: the missing foundation_uid validation on most of these. #2369 added validateFoundationUidParameter for the queue specifically because silently widening a filter the caller asked to narrow is the wrong failure direction. The same argument applies to every endpoint taking the param.
Refs #2378, #2380, #2368, #2369.
Summary
#2378 found the Formations queue returning 3 rows instead of 126 because foundation scoping matches a project's immediate parent rather than its ancestry, and the LF root's direct children are 3 of 126.
#2380 fixed that one endpoint. While doing so it found the same shape on five others sharing
ProjectService.getFoundationProjectUids:/api/committees/my-committees/api/user/meetings/api/user/past-meetings/api/user/latest-past-meetingsSeveral also lack the param validation #2369 added for
foundation_uidon the queue.Why it matters beyond the formations queue
The failure is silent in exactly the same way. A foundation with intermediate projects under it under-reports, and nothing on the page says so — the user sees a shorter list and has no reason to doubt it.
The formations queue made it obvious only because the root is the extreme case: 123 of 126 hidden. Elsewhere the gap will be smaller and therefore harder to notice, which does not make it less wrong. Production has 33 distinct parents across 126 formations, so intermediate nesting is the norm, not an edge case.
/api/committees/my-committeesis worth looking at first: #2369 cited it as the naming precedent for thefoundation_uidparam, so it is the endpoint most likely to share the queue's exact assumptions.What is not being claimed
I have not measured the under-report on any of these five. #2380 identified them by shared code path, not by observation. Someone should check each against production before deciding how urgent it is — the shape is the same but the impact depends on how many rows sit under intermediate parents in each case, and for some of them the answer may be none.
That measurement is the first task here, not the fix.
Relationship to the other two
If #2368 lands, most of this dissolves. If it does not land soon, each of these five needs its own decision, and the root special-case is the pattern to copy.
Worth deciding that at the top rather than per-endpoint — five copies of a workaround is how a workaround becomes the architecture.
Also
While in here: the missing
foundation_uidvalidation on most of these. #2369 addedvalidateFoundationUidParameterfor the queue specifically because silently widening a filter the caller asked to narrow is the wrong failure direction. The same argument applies to every endpoint taking the param.Refs #2378, #2380, #2368, #2369.