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

[Harxhit]

Summary

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

Contexts

The follow 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

(request as any).user = payload;

catch (error: any)

Some of these usages are related to authentication, OAuth integrations, request typing, and Fastify route handlers. 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 follow.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 (request as any).user with proper request typing
• Replace error: 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 follow.ts
• Existing shared Fastify/JWT types are reused where applicable
• Authenticated user access is properly typed
• Request objects use appropriate Fastify typings
• Authentication-related code uses proper Fastify types
• Error handling avoids unsafe any usage
• TypeScript checks pass successfully
• Existing follow 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.

[Jai-Shankar1033]

hey @ShantKhatri I'm a GSSoC'26 contributor and would love to work on it. Kindly assign it to me.

[hariom888]

1. The addHook('preHandler', ...) boilerplate (lines 9, 11, 12) — request.server as any, (app as any).authenticate, and (request as any).user = payload — the most defensive variant seen so far (it has a third fallback branch using raw jwtVerify() + manual request.user assignment, unlike profiles.ts's two-branch version).
2. (request.user as any).id (lines 22, 119, 151) — same FastifyJWT typing gap as the other three issues.
3. catch (error: any) (line 140) — in the /log POST handler's try/catch around app.prisma.followLog.create.

Proposed fix approach:

• Reuse the FastifyJWT payload/user augmentation from src/types/fastify.d.ts (shared with Improve Type Safety in profiles.ts and Remove Remaining any Usage #552/Improve Type Safety in team.ts and Remove Remaining any Usage #554) to resolve all 3 (request.user as any).id casts.
• Collapse the 3-branch preHandler to a single app.authenticate reference, same as proposed for profiles.ts and team.ts — once the FastifyInstance.authenticate decorator is properly typed, the server as any / (app as any).authenticate / manual jwtVerify() fallback chain becomes unnecessary; (request as any).user = payload goes away because app.authenticate sets request.user itself.
• catch (error: any) on line 140 → catch (error: unknown), narrowed via getErrorMessage(error) (already imported and used elsewhere in this file for the followGitHub error paths) for logging, with Prisma.PrismaClientKnownRequestError narrowing only if a specific Prisma error code needs distinct handling — otherwise a plain unknown + getErrorMessage is sufficient since the current code just logs and returns a generic 500.

Affected files: apps/backend/src/routes/follow.ts, apps/backend/src/types/fastify.d.ts (shared augmentation, reused from #552/#554).

Test considerations: Pure typing refactor — confirm __tests__/follow.test.ts (and connect.test.ts if it shares helpers) still pass, particularly the 401 "Unauthorized" path when jwtVerify() fails, and the /log endpoint's error → 500 path with Failed to log follow event. tsc --noEmit should report zero any in this file and no new errors elsewhere.

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

[yachikadev]

Hi! I'd like to work on this issue. I went through follow.ts and found the any usages mentioned in the description (server as any, app as any, request.user as any, (request as any).user, and catch (error: any)).
Before starting, I'll check the codebase for existing shared Fastify/JWT type definitions (e.g., module augmentation for FastifyRequest/FastifyInstance with @fastify/jwt) so I don't duplicate types that already exist elsewhere in the project. I'll then replace each any with the appropriate typed alternative, run tsc to confirm no new type errors, and update/run existing tests for follow routes to make sure functionality is unaffected.
Could you assign this to me? Happy to clarify scope if there's a preferred typing pattern already established in the codebase.

[Harxhit]

@yachikadev I have assigned this issue to you.