yikart/AiToEarn · error · AppException
ResponseCode.ValidationFailed
ResponseCode.ValidationFailed
Error message
ValidationFailed
What it means
ValidationFailed is thrown by ParseObjectIdPipe when a supplied string route/query parameter is defined but not a valid MongoDB ObjectId (24-char hex). Nest pipes run before the handler, so the request is rejected early with the standard ValidationFailed response code.
Source
Thrown at project/aitoearn-backend/libs/common/src/pipes/parse-object-id.pipe.ts:12
import { Injectable, PipeTransform } from '@nestjs/common'
import { isValidObjectId } from 'mongoose'
import { ResponseCode } from '../enums'
import { AppException } from '../exceptions'
@Injectable()
export class ParseObjectIdPipe implements PipeTransform<string | undefined> {
transform(value: string | undefined): string | undefined {
if (value === undefined || value === null)
return value
if (!isValidObjectId(value)) {
throw new AppException(ResponseCode.ValidationFailed)
}
return value
}
}
View on GitHub (pinned to d3aa8bea5b)
Solutions
- Ensure the client sends the actual 24-hex-char MongoDB _id
- Validate the ID format client-side (/^[0-9a-fA-F]{24}$/) before calling
- Check for truncation/sanitization in routing or query-string handling
- If legacy numeric IDs must be supported, remove the pipe or add a custom union pipe
Example fix
// before
api.get(`/users/${numericId}`) // numericId = 42
// after
if (!/^[0-9a-f]{24}$/.test(id)) throw new Error('invalid id')
api.get(`/users/${id}`) Defensive patterns
Strategy: validation
Validate before calling
const OBJECT_ID_RE = /^[0-9a-fA-F]{24}$/
if (!OBJECT_ID_RE.test(id)) throw new Error(`invalid ObjectId: ${id}`) Type guard
function isObjectId(v: unknown): v is string {
return typeof v === 'string' && /^[0-9a-fA-F]{24}$/.test(v)
} Try / catch
try {
await api.get(`/items/${id}`)
} catch (e) {
if (e.response?.data?.code === 'ValidationFailed') {
// surface 'invalid id' to user instead of generic failure
} else throw e
} Prevention
- Always use the raw MongoDB _id string from the API response
- Validate 24-hex-char format client-side before requests
- Watch for ID truncation in URL builders/templating
- Migrate clients fully when switching ID schemes
When it happens
Trigger: Passing a non-ObjectId string (numeric DB id, UUID, short code, empty-string after trimming) to a param decorated with @Param('id', ParseObjectIdPipe).
Common situations: Frontend switched from numeric IDs to ObjectIds (or vice versa) after a storage migration; IDs truncated in URLs; client stores IDs as JSON and loses formatting; testing with hardcoded placeholder IDs like '1' or 'test'.
Related errors
- Invalid ObjectId
- 任务素材不存在
- No subtitle entries in response
- No response from Gemini
- Invalid subtitle data: ${z.prettifyError(result.error)}
AI-assisted analysis of yikart/AiToEarn@d3aa8bea5b (2026-08-31).
Data as JSON: /api/errors/fc14d8970b591f47.
Report an issue: GitHub.