detect.ts uses manual join casts instead of the existing unwrapJoin helper

[jakharmonika364]

Summary

src/lib/maintainer/detect.ts has two places that query github_installation_users joined to github_installations!inner(...), then unwrap the result with a manual cast instead of the unwrapJoin helper that already exists in src/lib/supabase/inner-join.ts for exactly this:

• isUserMaintainer (line 27): (row as unknown as { github_installations: {...} | null }).github_installations
• listMaintainerInstalls (line 64): row as unknown as Row, same shape

This is the same join ambiguity that was already fixed once in mentor-assign.ts during the auto-assign mentor PR, Supabase can return an !inner join as either an object or a single element array depending on how the relationship is inferred, and unwrapJoin normalizes that safely. These two functions assume it's always an object.

Context

Both functions currently work in practice, but only because the join shape happens to come back as an object today. If that shape ever changes (schema tweak, Supabase client version bump), these casts won't catch it, unwrapJoin would.

Suggested fix

Replace both manual casts with unwrapJoin<{ uninstalled_at: string | null }>(row.github_installations) and the equivalent in listMaintainerInstalls, matching how process-pr-event.ts already does it for its own joins.

[diksha78dev]

@Ayush-Patel-56 I would like to work on this issue under GSSoC'26 and SSoC'26.

Proposed Solution

To resolve the join ambiguity and ensure type safety in src/lib/maintainer/detect.ts, I will replace the manual type casts with the existing unwrapJoin utility.

• Action: Refactor isUserMaintainer (line 27) and listMaintainerInstalls (line 64) in src/lib/maintainer/detect.ts.
• Implementation:
  • isUserMaintainer: Update the access pattern to use unwrapJoin<{ uninstalled_at: string | null }>(row.github_installations) to safely retrieve the installation object.
  • listMaintainerInstalls: Apply the same unwrapJoin normalization to ensure the query result is consistently handled regardless of whether Supabase returns an object or a single-element array.
  • Consistency: By adopting the unwrapJoin pattern already used in process-pr-event.ts, I will ensure the code remains resilient to future schema changes or Supabase client updates.
• Verification: I will perform a local test to verify that the maintainer detection and installation listing logic continues to function correctly with the refactored joins.

[Ayush-Patel-56]

Approach is right, matches how process-pr-event.ts does it. One ask: can you add a test that mocks github_installations as an array (e.g. [{ uninstalled_at: null }]) instead of an object, for both functions? Locally it'll always come back as an object so that won't catch the regression, we need a test that actually exercises the array shape, since that's the bug this fix exists for.

[diksha78dev]

Thanks for the feedback. I understand—I will add a test case that mocks github_installations as an array (e.g., [{ uninstalled_at: null }]) to ensure the unwrapJoin logic correctly handles that shape and avoids regressions. I'll get that updated in the PR

[Ayush-Patel-56]

also i suggest to split large PRs (above 100 lines of code) into 2 or 3. so you'll get more points in SSoC and GSoC.

[diksha78dev]

Noted.