Add field validation in updateProfile service method

[DeFiVC]

Bug Description

The updateProfile method in src/modules/users/user.service.ts (lines 82-112) directly spreads the request body into the database update without validating field constraints. While Zod schemas validate at the route level, the service method itself doesn't enforce limits.

Location

src/modules/users/user.service.ts lines 86-90

async updateProfile(
    userId: string,
    data: UpdateProfileBody,
): Promise<UserProfile> {
    const [updated] = await db
        .update(users)
        .set({ ...data, updatedAt: new Date() })
        .where(eq(users.id, userId))
        .returning();

The Problem

The method spreads data directly into the update. If the Zod schema is bypassed (e.g., by calling the service method directly from another service), the database could receive:

1. displayName longer than 100 characters (column limit)
2. pace longer than 20 characters
3. language longer than 10 characters
4. Null values for fields that should be strings

While the database will reject values exceeding column limits with an error, it's better to validate at the service level for:

• Clearer error messages
• Defense in depth
• Consistent validation regardless of call site

Recommended Fix

Add explicit validation in the service method:

async updateProfile(
    userId: string,
    data: UpdateProfileBody,
): Promise<UserProfile> {
    // Validate field lengths
    if (data.displayName && data.displayName.length > 100) {
        throw new ValidationError({ displayName: ["Display name must be 100 characters or less"] });
    }
    if (data.pace && data.pace.length > 20) {
        throw new ValidationError({ pace: ["Pace must be 20 characters or less"] });
    }
    // ... etc

    const [updated] = await db
        .update(users)
        .set({ ...data, updatedAt: new Date() })
        .where(eq(users.id, userId))
        .returning();

Acceptance Criteria

• Add field length validation in the service method
• Return clear validation errors for oversized fields
• Consider using a shared validation utility

Severity

low - Defense in depth. The Zod schema at the route level should catch these, but the service should be self-contained.

[blackmore-technology-group]

I reproduced this against current main and have a narrow service-boundary fix in progress. The service now reuses the existing updateProfileSchema at runtime so direct/internal callers receive the same length/type validation and sanitization as route callers, with ValidationError mapping and regression coverage for over-length and null inputs. Targeted tests and lint are green; the repo-wide typecheck currently has unrelated pre-existing syntax failures, which I'll call out separately in the PR.

[guptakumarranjeet150]

Hi there,

I can tackle Add field validation in updateProfile service method. Proposed implementation roadmap:

• Analysis: Inspect current behavior and edge cases in ChainLearnOfficial/chainlearn-api
• Core Implementation: Implement backend logic for Add field validation in updateProfile service method with strict schema validation and idempotent execution.
• Quality Assurance: Cover route handlers with automated endpoint integration tests.

Happy to pick this up today—please assign to me!