[mnapoli]

Summary

production tests fail: #990 (who to follow from the API) and #886 (GitHub README) were written against users.username, which #1157 dropped when handles moved to profiles.

• POST api/v1/users/{user}/dismiss bound users by username → now {user:handle}, like the other API user routes.
• The username filter of GET suggested users validated and looked up users.username → now profiles.handle. The parameter keeps its name, as the API's user resources still call the handle username.
• The README tests created users with username → handle.

Validation

• The 3 failing test files: 81/81 locally (isolated Postgres)
• tsc --noEmit: clean
• composer test:lint, composer test:type-coverage: pass
• bun run test:unit: 190/190
• pest --parallel --ci --coverage --exactly=100.0: 4492/4492, 100% coverage

Limitations

Pushed for speed before an independent review.

[coderabbitai]

Caution

Review failed

The pull request is closed.

Walkthrough

The suggested-user request validates and resolves users by profile handle. The dismissal route binds users by handle. Related API and README-tab tests now use handle attributes and parameters.

Changes: Suggested-user handle lookup

Layer / File(s)	Summary
Profile handle lookup and coverage app/Http/Requests/ListApiSuggestedUsersRequest.php, routes/api.php, tests/Feature/Controllers/Api/SuggestedUserControllerTest.php, tests/Feature/Controllers/UserControllerTest.php	The request validates a user profile by handle and resolves the user through its profile relation. The dismissal route binds by handle. Related test fixtures and requests use handles.

Priority: Not assessed

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Possibly related PRs

• dev-null-sh/dev-null.sh#990: Added the suggested-user API and dismissal route that this change updates.
• dev-null-sh/dev-null.sh#1156: Moved GitHub identity to profiles.handle and added profile-based route binding.
• dev-null-sh/dev-null.sh#1157: Made profiles the source of GitHub identity, which this change reflects in the suggested-user API.

Suggested reviewers: taldres

Merge Risk: Minimal · up to f26b2

The handle migration is consistent across the API request, dismissal route, model relation, and tests, with no merge-blocking risk identified.

Security architecture risk: Minimal · up to f26b2

The changes align user lookups with the existing profile-handle model. Authentication, dismissal ownership, and downstream visibility controls remain intact. No material security risk introduced or worsened by this PR was identified.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — The affected operations select contextual recommendations and record a dismissal owned by the authenticated user. The inspected flow does not grant callers authority to modify another user's dismissal collection.

Trust Boundaries and Controls

• observed — The dismissal route remains under required signed authentication. Its request rejects self-targeting, its owner comes from the authenticated current user, and its attacker-supplied handle is resolved to a User before persistence. These boundaries are unchanged from the base.

Resilience and Maintainability Implications

• inferred — Persisting User IDs keeps existing dismissal state independent of subsequent handle changes. If a response is interrupted after persistence, a retry resolving the same User preserves one logical dismissal; concurrent first-write behavior remains an unverified, pre-existing implementation dependency.

Finishing Touches

📝 Generate docstrings

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

[mnapoli]

Do we keep username for BC in the API?

We renamed it to handle, but then API clients would need to update too.