Improve Type Safety in profiles.ts and Remove Remaining `any` Usage

[Harxhit]

Summary

Improve type safety in profiles.ts by removing remaining usages of any and replacing them with proper Fastify, TypeScript, Prisma, and application-specific types.

Contexts

The profile routes currently contain several usages of any that bypass TypeScript's type checking and reduce maintainability.

Examples include:

const server = request.server as any;

(app as any).authenticate

(request.user as any).id

catch (err: any)

Some of these usages are related to authentication, Fastify route handlers, Prisma errors, and shared request/user typings. Existing shared Fastify/JWT type definitions should be reused where available instead of introducing duplicate definitions.

Removing these usages will improve maintainability, reduce unsafe casts, and make future refactoring easier.

Tasks

• Identify all remaining any usages in profiles.ts
• Use existing Fastify/JWT type definitions where available
• Replace server as any with appropriate Fastify types
• Replace app as any with appropriate Fastify types
• Replace request.user as any with properly typed user access
• Replace err: any with safer error handling patterns
• Improve authentication-related typing where applicable
• Verify TypeScript passes without introducing new type errors
• Update tests if required

Acceptance Criteria

• No any usages remain in profiles.ts
• Existing shared Fastify/JWT types are reused where applicable
• Authenticated user access is properly typed
• Authentication-related code uses proper Fastify types
• Error handling avoids unsafe any usage
• TypeScript checks pass successfully
• Existing profile functionality continues to work
• Tests pass successfully

Area

backend

Difficulty

Good First Issue

[github-actions]

Hi @Harxhit,

Thanks for opening this issue.

Please reply with one of the following areas so the issue can be routed to the appropriate team member:

- /backend
- /web
- /mobile
- /devops

Once an area is selected, the corresponding label will be added automatically.

[Harxhit]

/backend

[github-actions]

The issue has been classified as backend.

@Harxhit, please review and triage this issue when available.

The backend label has been applied and the issue has been routed accordingly.

[Srejoye]

1. The shared preHandler boilerplate (lines 27, 32-33) — request.server as any / (app as any).authenticate — same duplicated pattern as team.ts, but here it's a single app.addHook('preHandler', ...) applied to the whole route group, not repeated per-route, so the fix is more contained.
2. (request.user as any).id (lines 46, 55, 92, 111, 129, 145) — same root cause as Improve Type Safety in team.ts and Remove Remaining any Usage #554: request.user's type from @fastify/jwt isn't constrained to include id.
3. catch (err: any) (lines 82, 102, 120, 136, 151) — five catch blocks, each checking err?.code === 'P2002' for Prisma unique-constraint violations, then falling back to a generic 500.

Proposed fix approach:

• The FastifyJWT module augmentation proposed for Improve Type Safety in team.ts and Remove Remaining any Usage #554 (src/types/fastify.d.ts, declaring payload/user as { id: string; username: string }) resolves all 6 (request.user as any).id casts here too — this issue and Improve Type Safety in team.ts and Remove Remaining any Usage #554 should land with the same augmentation to avoid duplication; whichever PR lands first adds it, the other reuses it.
• For the preHandler: since profiles.ts already calls app.authenticate as a fallback ((app as any).authenticate), replace the whole defensive chain with a direct app.authenticate reference (typed via Fastify's FastifyInstance.authenticate decorator declaration — confirm this decorator is already declared somewhere, e.g. a plugin types file; if not, add interface FastifyInstance { authenticate: ... } augmentation alongside the JWT one).
• For catch (err: any): switch to catch (err: unknown) and narrow with Prisma.PrismaClientKnownRequestError (already imported/used elsewhere, e.g. team.ts's error instanceof Prisma.PrismaClientKnownRequestError) instead of the loose err?.code === 'P2002' optional-chain check on any.

Affected files: apps/backend/src/routes/profiles.ts, apps/backend/src/types/fastify.d.ts (shared augmentation).

Test considerations: Pure typing/narrowing refactor — no behavior change expected for the success paths. For the catch blocks, verify the P2002 → 409 "Username already taken" (and similar conflict) responses in __tests__/profiles.test.ts still trigger correctly with instanceof Prisma.PrismaClientKnownRequestError narrowing (Prisma errors must still be recognized as such after the type change — confirm the mocked/test Prisma client throws actual PrismaClientKnownRequestError instances, not plain objects with a .code). tsc --noEmit should pass with zero any in this file.

I'd like to take this under GSSoC'26.

[Satvik-art-creator]

@Harxhit I would like to work on this under GSSoC`26