Summary
Projects can have valid pending invitations in FOSSA, but maintainer‑d shows an empty PENDING INVITATIONS table after refresh. This happens even though the invites exist in FOSSA and were originally sent via maintainer‑d.
What follows is a AI based assesment of root cause. It is largely correct, the only part I do not fully agree with (or more accurately that I need to test and explore further) is the apparent un-reliability of FOSSA to report pennding inviations via my client's interaction with FOSSA REST API. I have yet to see evidence of that.
Observed behavior
- FOSSA UI shows pending invites for a project/team.
- GET /api/services/fossa/invites?projectId=... returns []. (RK a web-bff endpoint)
- Refresh logs show team members being fetched, but pendingInviteEmails=0.
- Poller may log “no pending invites found.”
Root cause (current behavior)
/api/services/fossa/invites/refresh treats FOSSA’s org‑wide pending invite list as the source of truth and soft‑deletes DB invite records when they aren’t present in the FOSSA response.
Because FOSSA pending invites are not team‑scoped and can disappear due to acceptance/expiry or API delays, this can incorrectly delete valid pending invites in maintainer‑d.
Maintainer‑d is supposed to record invites so we can track status and show pending invites per project. Soft‑deleting when FOSSA doesn’t seem to report them breaks that invariant and the UI loses visibility.
Desired behavior
- Pending invites should not be deleted solely because FOSSA doesn’t appear to list them. (Yes, but FOSSA is probably doing its job properly)
- Invites should only be deleted/cleared after we confirm the maintainer was added to the team (or another explicit terminal state).
- Refresh should reconcile status without dropping records.
Relevant code
cmd/web-bff/main.go → handleFossaInviteRefresh (the removal loop calling DeleteServiceInvitation)
Summary
Projects can have valid pending invitations in FOSSA, but maintainer‑d shows an empty PENDING INVITATIONS table after refresh. This happens even though the invites exist in FOSSA and were originally sent via maintainer‑d.
What follows is a AI based assesment of root cause. It is largely correct, the only part I do not fully agree with (or more accurately that I need to test and explore further) is the apparent un-reliability of FOSSA to report pennding inviations via my client's interaction with FOSSA REST API. I have yet to see evidence of that.
Observed behavior
Root cause (current behavior)
/api/services/fossa/invites/refresh treats FOSSA’s org‑wide pending invite list as the source of truth and soft‑deletes DB invite records when they aren’t present in the FOSSA response.
Because FOSSA pending invites are not team‑scoped and can disappear due to acceptance/expiry or API delays, this can incorrectly delete valid pending invites in maintainer‑d.
Maintainer‑d is supposed to record invites so we can track status and show pending invites per project. Soft‑deleting when FOSSA doesn’t seem to report them breaks that invariant and the UI loses visibility.
Desired behavior
Relevant code
cmd/web-bff/main.go → handleFossaInviteRefresh (the removal loop calling DeleteServiceInvitation)