Collaborator invite never links to an account and becomes an orphan (504 on add, cannot be removed)

[douglasmariano-gazin]

Inviting a collaborator by email does not work end to end. collaborator add times out at the gateway (HTTP 504) but still writes a record, no invitation email is sent, and the invited person is never linked to the app. When they log in later they get a brand-new, unlinked account instead of joining the app. The pending invite then becomes an orphan that blocks any re-add and cannot be removed with collaborator rm.

There appear to be two independent data structures that are never reconciled: active collaborators (shown by ls, removable by rm) and pending invites (created by add). rm only touches active collaborators, so a pending invite can never be cleaned up, and registration/login never promotes a pending invite into an active collaboration.

This happens both via the CLI and via the web UI — adding a collaborator through the browser fails with the same 504 Gateway Time-out (screenshot attached below as evidence).

To Reproduce
The same failure happens through both the web UI and the CLI. Via the web UI: as the app owner, open the app, add a collaborator by email, and submit → the request fails with a 504 Gateway Time-out (see attached screenshot). The CLI reproduction below shows the underlying state in more detail.

Steps to reproduce via the CLI (run as the app owner):

1. Invite an email that does not yet have a NextPush account:
   nextpush collaborator add MyApp collaborator@example.com
   → Hangs ~60s and returns an nginx 504 Gateway Time-out. No invitation email is sent.
2. Run the same command again:
   nextpush collaborator add MyApp collaborator@example.com
   → Returns immediately: The specified account is already invited to this app (so step 1 did persist a pending invite despite the 504).
3. nextpush collaborator ls MyApp
   → Shows only the owner; the invited email does not appear.
4. Have collaborator@example.com open https://nextpush.center and log in / register with that exact email.
   → A new, separate account is created and the user is not added to MyApp.
5. Try to fix it as the owner:
   nextpush collaborator rm MyApp collaborator@example.com (confirm y)
   → {"error":"Collaborator not found"}
   nextpush collaborator add MyApp collaborator@example.com
   → The specified account is already invited to this app
   The email is now stuck: add is blocked by the pending invite, rm cannot remove it, and it never appears in ls. Reproduced consistently across multiple apps.

Expected behavior

• collaborator add completes without a gateway timeout and sends the invitation email.
• When the invited person registers/logs in with that email, the pending invite is promoted to an active collaboration (and if their account already exists at add time, add links it immediately).
• The collaborator then appears in collaborator ls, and orphaned/pending invites can be removed.

Screenshots

Screenshot of the same 504 Gateway Time-out reproduced when adding a collaborator through the web UI is attached below as evidence.

Relevant server responses observed via the CLI:

• add → 504 Gateway Time-out (nginx), then The specified account is already invited to this app on retry
• rm → {"error":"Collaborator not found"}
• ls → only the owner is listed

Desktop:

• OS: Debian with WSL2 - Running via CLI
• Browser: also reproduced via the web UI (Chrome) — same 504 on add
• Version: nextpush-cli 1.1.0; server nextpush.center / api.nextpush.center (behind nginx)

Additional context

Likely fixes:

1. Promote pending invites on registration/login: when an account is created or logs in with an email that has a pending invite, convert the invite into an active collaboration. Ensure email matching is case-insensitive / normalized.
2. Make add idempotent against existing accounts: if the email already has an account, link it immediately instead of leaving a dangling invite.
3. Allow managing/removing pending invites (extend collaborator rm to clear them, or add a dedicated command) so orphans can be recovered without DB access.
4. Fix the invite-email step causing the 504 — make it async / non-blocking so the API responds promptly and the email is actually delivered.

Impact: collaborators cannot be added through the normal flow (CLI or web UI). Any email invited before the person had an account is now orphaned and blocks the correct flow, with no self-service way to recover.