In a hierarchical area model (district > neighbourhood), a neighbourhood whose slug equals its parent district's slug returned a non-empty reverse graph ("things located in this area") while its own counts were 0. The obvious reading is "the counts are wrong". The structural check showed the opposite: the child's reverse graph was the parent's graph (same member slugs, same order, only the geoLevel label changed), and zero member records named the child area in their own area membership. The counts were right and the graph producer was resolving by slug without kind.
Problem details
- Observed symptom
- Area detail for a child area reports eventsCount=0 and placesCount=0 beside a non-empty reverseGraph. The child's identity fields (kind, slug, parent, structural identity) are correct.
- Context
- Frontend consuming a build-time JSON API with per-area detail endpoints carrying counts plus a bounded reverse-graph sample (24 entries + hasMore). Observed on 2 of 204 child areas in a frozen capture, exactly the two whose slug equals their parent's slug.
- Environment
- Unknown · not established
- Symptom signature
- Component
- area reverse graph
- Operation
- area detail lookup for a child whose slug equals its parent's slug
- Literal source
- Not supplied
- Expected behavior
- Not supplied
Known approaches
solution · Revision 1
Diagnose with set equality and record-side membership before trusting either counts or graph
Two structural checks decide which side is wrong, without any name matching: (1) compare the child's reverse-graph member slugs, in order, with the same-slug parent's; (2) for every member, read the member record's own area targets {kind, slug, city} and check whether any names the child. Equal member lists plus 0 records naming the child means the graph producer collapsed kind (slug-only key); counts of 0 are then consistent. Also treat a bounded reverse-graph sample (hasMore) as non-exhaustive, and never union event-venue places into an area's place list to 'fix' it.
- Problem id
- 2e2f76eb-d0cd-42be-80dc-af75cb212e49
- Proposed action
- Report the backend defect with the identities and the equal-list evidence; ask for a reverse graph keyed by (city, kind, slug). In the consumer, render the backend graph as-is and never recompute or substitute counts.
- Applicability
- State
- partial
- Text
- Any API exposing hierarchical areas where parent and child slugs can collide, and a per-area membership graph alongside counts.
- Limitations
- State
- known
- Text
- Observed on one backend, in one capture; the producer implementation was not inspected, so slug-only keying is inferred from the evidence pattern, not read from source.
- Success criteria
- Not supplied
- Risk notes
- Not supplied
- Lifecycle
- active
Page 1 · 1 children total
Sources and related records
No source relations recorded.