Forem: Rhico

Why My Prisma P2002 Was Escaping try/catch in NestJS

Rhico — Wed, 15 Apr 2026 16:58:24 +0000

I'm building RunHop in public, a social + event platform for running races. Today I worked on the Reactions module: likes on posts.

The module itself was straightforward:

POST /posts/:id/likes
DELETE /posts/:id/likes
a ReactionService that talks to Prisma's postLike model
unit tests and e2e coverage for the happy path and duplicate-like path

The interesting bug was in the duplicate-like flow.

The Service Looked Correct

I had this shape in src/domain/social/reaction/reaction.service.ts:

async like(postId: string, userId: string) {
    const post = await this.postService.findById(postId);

    if (!post) throw new NotFoundException('Post not found');

    try {
        return this.prisma.postLike.create({
            data: { postId, userId },
        });
    } catch (error) {
        if (
            error instanceof PrismaClientKnownRequestError &&
            error.code === 'P2002'
        ) {
            throw new ConflictException('Duplicate like');
        }

        throw error;
    }
}

At a glance it feels fine. There's a try/catch, Prisma throws P2002 for a unique constraint violation, and I map it to ConflictException.

But the unit test still failed.

Why It Failed
postLike.create() returns a promise. When that promise rejects, the rejection happens asynchronously.

Because I returned the promise directly from inside the try block, the function exited before the rejection occurred. The catch block never saw the Prisma error.

So instead of this:

Prisma rejects with P2002
service catches it
Nest gets ConflictException

I got this:

Prisma rejects with P2002
promise escapes
raw Prisma error bubbles up
The Fix
The fix was to await inside the try block:

try {
    return await this.prisma.postLike.create({
        data: { postId, userId },
    });
} catch (error) {
    if (
        error instanceof PrismaClientKnownRequestError &&
        error.code === 'P2002'
    ) {
        throw new ConflictException('Duplicate like');
    }

    throw error;
}

This is one of the few cases where return await is exactly what you want. It keeps the rejected promise inside the try/catch boundary.

The Rest of the Module

I also added:

ownershipCheck(likeId, userId) so only the owner can delete a like unlike() mapping Prisma P2025 to NotFoundException
an e2e test that does the full flow:
register
create post
like
duplicate like -> 409
unlike
unlike again -> 404

One design detail I still want to revisit: the delete route is DELETE /posts/:id/likes, but the :id there is currently a like id, not a post id. It works, but the route shape is carrying two meanings between create and delete.

Takeaway

The useful reminder from this session:

try/catch only catches what stays inside it.

If you need to translate async database errors into framework exceptions, you need the rejected promise to be awaited inside the try block.

Why !false Broke My API: Building a Polymorphic Follow System in NestJS

Rhico — Mon, 13 Apr 2026 23:50:55 +0000

I'm building RunHop in public — a social + event platform for running races, built on NestJS.

Today I built the Follow module, and the most interesting problem wasn't the polymorphic design — it was a one-line bug in a response interceptor that silently ate boolean values.

The Module: Polymorphic Follows

Users can follow three types of things: other users, organizations, and events. Instead of three separate tables (user_follows, org_follows, event_follows), there's one Follow table with a targetId and targetType enum:

const targetTypeMap: Record<string, TargetType> = {
    USER: TargetType.USER,
    ORGANIZATION: TargetType.ORGANIZATION,
    EVENT: TargetType.EVENT,
};

The trade-off: the database can't enforce foreign keys on targetId because it could point to any of three tables. So validation happens at the application layer:

private async validateTargetExists(targetId: string, targetType: TargetType): Promise<void> {
    let exists: boolean;

    switch (targetType) {
        case TargetType.USER:
            exists = await this.userService.exists(targetId);
            break;
        case TargetType.ORGANIZATION:
            exists = await this.orgService.exists(targetId);
            break;
        case TargetType.EVENT:
            exists = await this.eventService.exists(targetId);
            break;
        default:
            throw new BadRequestException(`Invalid target type: ${targetType}`);
    }

    if (!exists) {
        throw new NotFoundException(`${targetType} not found.`);
    }
}

This makes the Follow module the only Phase 1 module that imports all three other contexts. It validates across boundaries but doesn't understand the internals of any of them — it only calls .exists().

The Bug: `!false === true`

The isFollowing method checks whether a follow relationship exists and returns a boolean:

async isFollowing(followerId: string, targetId: string, targetType: string) {
    const follow = await this.prismaService.follow.findUnique({
        where: {
            followerId_targetId_targetType: {
                followerId, targetId,
                targetType: targetTypeMap[targetType],
            },
        },
    });

    return !!follow;
}

This returns true or false. Clean. Correct. But the API was returning { data: null } instead of { data: false }.

The culprit was the global TransformInterceptor:

intercept(context: ExecutionContext, next: CallHandler): Observable<any> {
    return next.handle().pipe(
        map((response) => {
            if (!response) {          // <-- this line
                return { data: null };
            }
            if (response.data && response.meta) {
                return response;
            }
            return { data: response };
        }),
    );
}

!false evaluates to true. So when isFollowing returned false, the interceptor treated it as an empty response and replaced it with null.

The fix:

if (response === null || response === undefined) {
    return { data: null };
}

Strict equality. false passes through to return { data: response } and becomes { data: false }.

Route Collisions in NestJS

Another gotcha: I had GET /users/following in the FollowController and GET /users/:id in the UserController. NestJS matched :id first, interpreting "following" as a user ID, and returned a 404 from UserService.findById("following").

Parameterized routes are greedy — :id matches any string. If you have a static route at the same depth, the param route wins if it's registered first. The fix was changing to GET /users/me/following, which has a different shape and doesn't collide.

Worth knowing: GET /users/:id/followers (three segments) doesn't conflict with GET /users/:id (two segments). NestJS only matches routes with the same segment count.

E2E Testing Strategy

The e2e test creates 5 accounts in the first beforeAll, caches them in a listNewAccounts array, and reuses them across four different describe blocks:

let listNewAccounts: ResponseUser[] = [];

// In listFollowing beforeAll:
listNewAccounts.push(newAccount.body.data);

// In listFollowers beforeAll:
for (const newAccount of listNewAccounts) {
    await request(app.getHttpServer())
        .post('/api/v1/follows')
        .set('Authorization', `Bearer ${newAccount.accessToken}`)
        .send({ targetId: targetUser.user.id, targetType: 'USER' });
}

Same 5 accounts follow the target user, then the test org, then the test event. No redundant registrations. The isFollowing tests pick randomly from the cached list to verify both true and false cases.

Takeaway

Falsy coercion in middleware or interceptors is a subtle bug class. !response catches false, 0, and "" along with null and undefined. If your API can legitimately return any falsy value, use strict equality checks. The interceptor worked fine for months because every endpoint returned objects or null — it only broke when isFollowing introduced the first boolean return.

Prisma Errors Aren't All the Same: Building a Registration Module in NestJS

Rhico — Thu, 09 Apr 2026 13:40:34 +0000

I'm building RunHop in public — a social + event platform for running races, built on NestJS.

Today I built the Registration module, and the most interesting part wasn't the business logic — it was realizing that Prisma methods fail in fundamentally different ways, and you need to handle each one differently.

The Module

Registration enforces three rules:

The parent event must be PUBLISHED
The race must have capacity
A user can only register once per race (unique constraint on userId + raceId)

The service has six methods: create, cancel, confirm, listByRace, listByUser, and findById. The controller exposes five endpoints, including an empty-body POST — raceId comes from the URL, userId comes from the JWT.

The Problem: Three Failure Modes

Here's where it got interesting. I initially treated all Prisma errors the same way. That's wrong.

`findUnique` returns `null`

async findById(id: string) {
    return this.prisma.registration.findUnique({
        where: { id },
    });
}

When the record doesn't exist, findUnique returns null. It does not throw. If you wrap this in a try/catch for P2025, that catch block will never fire.

For cancel, where I need the registration to check ownership, the correct approach is a null guard:

async cancel(registrationId: string, userId: string) {
    const registration = await this.prisma.registration.findUnique({
        where: { id: registrationId },
    });

    if (!registration) {
        throw new NotFoundException('Registration not found.');
    }

    if (registration.userId !== userId) {
        throw new ForbiddenException('You can only cancel your own registration');
    }

    return await this.prisma.registration.update({
        where: { id: registrationId },
        data: { status: 'CANCELLED' },
    });
}

update throws P2025

async confirm(registrationId: string) {
    try {
        return await this.prisma.registration.update({
            where: { id: registrationId },
            data: { status: 'CONFIRMED' },
        });
    } catch (error) {
        if (
            error instanceof Prisma.PrismaClientKnownRequestError &&
            error.code === 'P2025'
        ) {
            throw new NotFoundException('Registration not found.');
        }
        throw error;
    }
}

When update can't find a matching record, it throws PrismaClientKnownRequestError with code P2025. This is different from findUnique — you need the try/catch here.

create throws P2002

try {
    return await this.prisma.registration.create({
        data: { userId, raceId },
    });
} catch (error) {
    if (
        error instanceof Prisma.PrismaClientKnownRequestError &&
        error.code === 'P2002'
    ) {
        throw new ConflictException('You are already registered for this race.');
    }
    throw error;
}

When a unique constraint is violated, create throws P2002. This is how the database enforces "one registration per user per race" — the schema has a @@unique([userId, raceId]), and Prisma surfaces the violation as a typed error.

Status Filtering

I added optional status filtering to listByUser. The approach: a registrationStatus map keyed by string, validated with the in operator, then spread conditionally into the Prisma query:

const registrationStatus: Record<string, RegistrationStatus> = {
    PENDING: RegistrationStatus.PENDING,
    CONFIRMED: RegistrationStatus.CONFIRMED,
    CANCELLED: RegistrationStatus.CANCELLED,
};

async listByUser({ userId, cursor, take = 20, status }: { ... }) {
    if (!!status && !(status.toUpperCase() in registrationStatus)) {
        throw new BadRequestException('Invalid registration status.');
    }

    const args: Prisma.RegistrationFindManyArgs = {
        take,
        where: {
            userId,
            ...(status && {
                status: registrationStatus[status.toUpperCase()],
            }),
        },
        orderBy: { registeredAt: 'asc' },
    };
    // ... cursor logic, return paginated result
}

Case-insensitive, type-safe, and the query only includes the status filter when a value is provided.

Testing With Realistic Data

The e2e test creates 30 registrations in a loop, using i % 3 to distribute statuses:

for (let i = 0; i < 30; i++) {
    // create event, race, publish, register...

    if (i % 3 === 0) {
        // confirm registration
    }
    if (i % 3 === 1) {
        // cancel registration
    }
    // i % 3 === 2 remains PENDING
}

This gives 10 of each status without separate setup blocks. Clean, predictable, and easy to assert against with ?status=confirmed&limit=5.

Takeaway

Prisma's error handling isn't uniform. findUnique returns null, update/delete throw P2025, create throws P2002 on constraint violations. Treating them the same leads to dead catch blocks or unhandled nulls. Match the error handling to the method's actual failure mode.

When a Passing Test Lies: Fixing an E2E False Positive in NestJS

Rhico — Fri, 03 Apr 2026 13:38:03 +0000

I’m building RunHop in public — a social + event platform for running races, built on NestJS.

Today wasn’t a feature day. It was a correctness day. I found a test that passed while testing the wrong behavior, and fixed a quiet 500 hiding behind a non-null assertion. Both are easy to miss, and both are exactly how bugs slip into production.

The Bug: An E2E Test That Didn’t Test Updates

In the Race module, I enforce a rule: once an event is published, races under it can’t be created, updated, or deleted.

I had an e2e test named:

it('should be 400 if updating a race on a published event', async () => { // draftEvent here is now published because of beforeAll const res = await request(app.getHttpServer()) .post(/api/v1/events/${draftEvent.id}/races) .set('Authorization', Bearer ${accessToken}) .send({ name: 'Race Test 2', distance: 123.45, unit: 'test-unit-2', maxParticipants: 500, price: 1000 });

expect(res.statusCode).toBe(400); });

The problem is obvious once you stare at it: this test is calling POST /events/:id/races — which is the create endpoint. It wasn’t testing updates at all. The test passed, but for the wrong reason.

This is the dangerous kind of bug: it gives you confidence you didn’t earn.

The Fix

I changed it to call the correct update endpoint:

it('should be 400 if updating a race on a published event', async () => {
  const res = await request(app.getHttpServer())
    .patch(`/api/v1/races/${raceTest2.id}`)
    .set('Authorization', `Bearer ${accessToken}`)
    .send({ name: 'Updated Race Test' });

  expect(res.statusCode).toBe(400);
});

That’s it. Same assertion, correct endpoint. Now the test actually verifies the rule I care about.

The Other Bug: Non-Null Assertions Hiding 500s

In RaceService, I had:

async findById(id: string) {
  return this.prismaService.race.findUnique({ where: { id } });
}

Every caller did this:

const race = await this.findById(id);
await this.verifyEventIsDraft(race!.eventId);

If a race didn’t exist, findUnique() returned null. The non-null assertion (race!) then caused a runtime error when accessing race!.eventId. That’s a 500, and it’s the worst kind: a missing record should be a 404, not an internal crash.

The Fix

I moved the not-found handling into findById():

async findById(id: string) {
  const result = await this.prismaService.race.findUnique({ where: { id } });
  if (!result) throw new NotFoundException('Race not found');
  return result;
}

Now every caller gets a consistent 404 for missing races, and I can remove defensive checks everywhere else.

Why This Matters

These changes are small, but they keep the system honest:

The e2e tests now prove what they say they prove.
The service layer returns correct HTTP errors instead of crashing.
It’s easy to chase new features and ignore this kind of cleanup. But if you’re building in public (or building at all), correctness work is what keeps the platform stable as it grows.

Takeaway

Passing tests don’t mean correct behavior. Look at the HTTP calls. Make sure the tests are hitting the right routes. And when you see ! on a nullable value, treat it as a warning — it’s often hiding a missing NotFoundException.

A State Machine in 10 Lines: Event Status Transitions in NestJS

Rhico — Wed, 01 Apr 2026 17:01:47 +0000

I'm building RunHop in public — a social + event platform for running races, built on NestJS.

Today I built the Event module: full CRUD, cursor-based pagination, and a status state machine that controls an event's lifecycle. The state machine was the interesting part.

The Problem

Events in RunHop go through four stages: DRAFT → PUBLISHED → CLOSED → COMPLETED. Not every transition is valid — you can't jump from DRAFT to CLOSED, and you can't go backwards from COMPLETED. There's also one special case: PUBLISHED → DRAFT is allowed, but only if nobody has registered yet.

I've seen state machines implemented with dedicated libraries, switch statements spanning hundreds of lines, or class hierarchies with a State interface. For four states and a handful of transitions, all of that is overkill.

The Implementation

The entire transition map:

// event.service.ts
const VALID_TRANSITIONS: Record<string, string[]> = {
    DRAFT: ['PUBLISHED'],
    PUBLISHED: ['DRAFT', 'CLOSED'],
    CLOSED: ['COMPLETED'],
    COMPLETED: []
};

Five lines. Each status maps to an array of valid next states. COMPLETED maps to an empty array — it's a terminal state.

The updateStatus() method:

async updateStatus(id: string, dto: UpdateEventStatusDto) {
    const event = await this.findById(id);

    const validTransitions = VALID_TRANSITIONS[event.status.toUpperCase()];
    if (!validTransitions.includes(dto.status.toUpperCase())) {
        throw new BadRequestException(
            `Cannot transition from ${event.status} to ${dto.status}`
        );
    }

    // Special case: PUBLISHED → DRAFT only if no confirmed registrations
    if (event.status === 'PUBLISHED' && dto.status === 'DRAFT') {
        const registration = await this.prisma.registration.count({
            where: {
                race: { eventId: id },
                status: 'CONFIRMED'
            }
        });

        if (registration > 0) {
            throw new BadRequestException(
                'Cannot revert to DRAFT — event has confirmed registrations',
            );
        }
    }

    return this.prisma.event.update({
        where: { id },
        data: { status: dto.status }
    });
}

Look up the current status. Check if the requested status is in the allowed list. If not, throw. If it's the special PUBLISHED → DRAFT case, check registrations. Then update.

Adding a new status or transition later is a one-line change to the map.

The Date Format Gap

The other interesting problem today was a mismatch between validation and storage.

The CreateEventDto uses @IsDateString() from class-validator to validate date inputs:

@IsDateString()
startDate!: string;

@IsDateString() accepts any valid ISO-8601 string — including date-only formats like 2026-06-01. But Prisma's DateTime type requires the full format: 2026-06-01T00:00:00.000Z. So a request with startDate: "2026-06-01" passes validation, enters the service, and then Prisma throws:

Invalid value for argument startDate: premature end of input.
Expected ISO-8601 DateTime.

There's a gap between "valid input" and "what the ORM accepts." The fix is a @Transform decorator from class-transformer that coerces the value after validation:

@IsDateString()
@Transform(({ value }) => new Date(value).toISOString())
startDate!: string;

Now the API accepts both 2026-06-01 and 2026-06-01T00:00:00.000Z. The transform runs after validation (important — you don't want to transform invalid input), and by the time the value reaches the service, it's always in the full format Prisma expects.

One thing to make sure: your ValidationPipe has transform: true enabled, otherwise @Transform decorators don't run:

app.useGlobalPipes(new ValidationPipe({ whitelist: true, transform: true }));

Cross-Field Validation

While building the DTOs, I needed endDate to be after startDate. class-validator doesn't have a built-in cross-field comparison, so I wrote a custom decorator:

// src/common/validators/is-after.validator.ts
export function IsAfter(property: string, validationOptions?: ValidationOptions) {
    return function (object: Object, propertyName: string) {
        registerDecorator({
            name: 'isAfter',
            target: object.constructor,
            propertyName,
            constraints: [property],
            options: validationOptions,
            validator: {
                validate(value: any, args: ValidationArguments) {
                    const [relatedPropertyName] = args.constraints;
                    const relatedValue = (args.object as any)[relatedPropertyName];
                    return new Date(value) > new Date(relatedValue);
                }
            }
        });
    };
}

Usage in the DTO:

@IsDateString()
@Transform(({ value }) => new Date(value).toISOString())
@IsAfter('startDate', { message: 'end date must be after start date' })
endDate!: string;

registerDecorator is the class-validator API for custom validation rules. The constraints array holds the name of the field to compare against, and args.object gives access to the full DTO instance so you can read the other field's value.

Extracting Shared Logic

The organization module had a generateSlug() method that turned names into URL-friendly slugs. The event module needs the same thing. Rather than duplicate it, I extracted it into GenerateSlugService in src/common/:

@Injectable()
export class GenerateSlugService {
    generateSlug(name: string): string {
        const res = name
            .toLowerCase()
            .replace(/\s+/g, '-')
            .replace(/[^a-z0-9-]/g, '')
        return `${res}-${randomUUID().slice(0, 8)}`;
    }
}

The UUID suffix prevents collisions without needing a retry loop or a uniqueness check query. manila-runners-club-a3f8b2c1 is unique enough for a slug.

Both OrganizationService and EventService now inject GenerateSlugService instead of each having their own copy.

E2E vs Unit: Know Which Assertion Style You're In

One mistake I caught during testing: using .rejects.toThrow(BadRequestException) in an e2e test. In a unit test, where you're calling service.updateStatus() directly, exceptions propagate and you can catch them with rejects.toThrow(). In an e2e test, supertest sends an HTTP request. NestJS exception filters catch the BadRequestException and return a 400 response. Supertest always resolves — it never rejects.

Unit test (calling service directly):

await expect(service.updateStatus('id', { status: 'CLOSED' }))
    .rejects.toThrow(BadRequestException);
E2E test (HTTP via supertest):

const result = await request(app.getHttpServer())
    .patch(`/api/v1/events/${event.id}/status`)
    .send({ status: 'CLOSED' });

expect(result.statusCode).toBe(400);

Different layers, different assertion patterns.

Takeaway

A state machine doesn't need a library. If your transitions fit in a Record<string, string[]>, that's the right abstraction. The map is readable, testable, and extensible. The special cases (like the registration check for PUBLISHED → DRAFT) live in the method that uses the map — not in the map itself. Keep the data structure simple and put the logic where it belongs.

Mock What Prisma Returns, Not What Your API Returns

Rhico — Mon, 30 Mar 2026 02:10:21 +0000

I'm building RunHop in public — a social + event platform for running races, built on NestJS.

Today I finished the organization and membership e2e test suites. Along the way, I spent an embarrassing amount of time on a TypeError that came down to one wrong mock.

The Crash

// organization.service.ts
async list(cursor?: string, take: number = 20) {
    const args: Prisma.OrganizationFindManyArgs = {
        take,
        where: { deletedAt: null },
        orderBy: { createdAt: 'desc' }
    };

    if (cursor) {
        args.skip = 1;
        args.cursor = { id: cursor }
    }

    const result = await this.prisma.organization.findMany(args);
    const nextCursor = result.at(-1)?.id;

    return { data: result, meta: { cursor: nextCursor } };
}

The unit test:

it('should return orgs without cursor', async () => {
    mockPrisma.organization.findMany.mockResolvedValue(
        { data: [mockOrg], nextCursor: mockOrg.id }  // <-- the problem
    );
    const result = await service.list();
    // TypeError: result.at is not a function
});

result.at(-1) crashed because the mock returns an object, not an array. And .at() is an Array method.

Why This Happens

The mock was shaped like the API response — { data: [...], nextCursor: '...' }. That's what the frontend sees. But Prisma's findMany returns a plain array. Always. The { data, meta } wrapping happens later, in a completely different layer.

Here's the actual data flow in a NestJS app with a response interceptor:

Prisma findMany  →  returns [org1, org2, org3]        (plain array)
     ↓
Service          →  returns { data: [...], meta: {} }  (structured response)
     ↓
Controller       →  returns service result as-is
     ↓
TransformInterceptor  →  sees data + meta keys → passes through untouched
     ↓
HTTP Response    →  { data: [...], meta: { cursor: '...' } }
For non-paginated endpoints, the interceptor wraps automatically:

Service          →  returns { id: '123', name: 'Org' }  (plain object)
     ↓
TransformInterceptor  →  no data/meta keys → wraps in { data: response }
     ↓
HTTP Response    →  { data: { id: '123', name: 'Org' } }
The interceptor code is straightforward:

// transform.interceptor.ts
@Injectable()
export class TransformInterceptor<T> implements NestInterceptor<T, any> {
    intercept(context: ExecutionContext, next: CallHandler): Observable<any> {
        return next.handle().pipe(
            map((response) => {
                if (!response) return { data: null };
                if (response.data && response.meta) return response;
                return { data: response };
            })
        );
    }
}

When you write a unit test for the service, you're testing everything above the controller. The mock replaces Prisma — so it should return what Prisma returns:

mockPrisma.organization.findMany.mockResolvedValue([mockOrg]); // plain array

The Pagination Test That Compared a List to Itself

While I was at it, I wrote a pagination e2e test that verified page 2 doesn't overlap with page 1. First attempt:

const newList = result.body.data;
const bIds = new Set(newList.map((item) => item.id));
const same = listOrgs.length === newList.length
    && newList.every((item) => bIds.has(item.id));

expect(same).toBe(false);

This always passes. bIds is built from newList, and then we check if every item in newList is in bIds. Of course it is — we're comparing the list against itself.

The fix:

const page2Ids = new Set(newList.map((item) => item.id));
const hasOverlap = listOrgs.some((item) => page2Ids.has(item.id));

expect(hasOverlap).toBe(false);

Now we're checking: do any page 1 items appear in page 2? That's the actual invariant.

Membership E2E: Permission Boundaries

The org-membership suite tests 6 scenarios from the plan:

describe('Add a member', () => {
    it('should create and return org membership');         // 201
    it('should reject duplicate member');                   // 409
});

describe('Update Member', () => {
    it('should update member role as owner');               // 200
    it('should reject role update as admin');               // 403
});

describe('Remove member', () => {
    it('should remove a member');                           // 200
    it('should reject removing owner');                     // 403
});

Setup is three users with distinct roles: owner creates the org (gets OWNER automatically via the transaction in create()), admin gets added with ADMIN role, member gets added with default MEMBER role. Tests run sequentially because membership state carries between them — the admin added in the update suite's beforeAll is still there for the remove tests.

The permission model: the controller calls verifyRole(userId, orgId, minRole) before every mutation. The service checks the caller's role against a hierarchy map:

const ROLE_HIERARCHY: Record<string, number> = {
    MEMBER: 1,
    ADMIN: 2,
    OWNER: 3
};

OWNER can do everything. ADMIN can add and remove members but not change roles. MEMBER can't mutate anything.

Takeaway

Mock the layer you're replacing, not the layer you're consuming. If you're mocking Prisma, return what Prisma returns. If you're mocking a service, return what the service returns. The moment your mock matches a different layer's shape, your test is lying to you — and you'll chase TypeErrors that have nothing to do with your actual logic.

Why My Unit Tests Passed But My App Was Broken

Rhico — Fri, 27 Mar 2026 22:37:52 +0000

I'm building RunHop in public — a social + event platform for running races, built on NestJS.

Today I set up e2e test infrastructure: dedicated test database, automatic resets, proper isolation. And within the first run, the e2e tests caught a bug that unit tests had been blind to for days.

The Bug Unit Tests Can't See

Here's the controller method that passed every unit test:

// organization.controller.ts
@Patch(':id')
async update(
    @CurrentUser() user: interfaces.AuthenticatedUser,
    @Param('id') id: string,
    dto: UpdateOrganizationDto  // <-- spot the problem?
) {
    await this.membershipService.verifyRole(user.userId, id, 'ADMIN');
    return this.orgService.update(id, dto);
}

The dto parameter is missing @body(). Without that decorator, NestJS never parses the request body into the DTO. The value is always undefined.

Here's the unit test that passed:

it('should update org fields', async () => {
    mockPrisma.organization.update.mockResolvedValue({ ...mockOrg, name: 'New Name' });
    const result = await service.update('id-123', { name: 'New Name' });

    expect(mockPrisma.organization.update).toHaveBeenCalledWith({
        where: { id: 'id-123' },
        data: { name: 'New Name' }
    });
    expect(result).toEqual({ ...mockOrg, name: 'New Name' });
});

See why it passes?

service.update('id-123', { name: 'New Name' })

calls the service directly.

No HTTP request. No controller. No decorators. The DTO is passed as a plain argument.

The e2e test caught it immediately:

it('should be able to update org as owner', async () => {
    const org = await request(app.getHttpServer())
        .patch(`/api/v1/organizations/${orgSaved.id}`)
        .set('Authorization', `Bearer ${accessToken}`)
        .send({
            name: 'New name',
            description: 'New Description'
        });

    expect(org.statusCode).toBe(200);  // fails — dto is undefined
});

The fix is one word:

@Body() dto: UpdateOrganizationDto

But the point isn't the fix. The point is that unit tests and e2e tests catch fundamentally different categories of bugs. Unit tests verify logic. E2e tests verify wiring.

Setting Up a Dedicated Test Database

Before writing e2e tests, I needed test isolation. Tests hitting the dev database is a recipe for pain.

The setup: a .env.test file pointing to a separate runhop_test database:

.env.test
DATABASE_URL=postgresql://runhop:runhop@localhost:5432/runhop_test

And a Jest globalSetup file that resets the database before every run:

// test/e2e-setup.ts
import { execSync } from "child_process";
import * as dotenv from 'dotenv';

export default async function () {
    dotenv.config({
        path: '.env.test',
        override: true
    });

    execSync('npx prisma migrate reset --force', { stdio: 'inherit' });
}

This loads .env.test, then runs

prisma migrate reset --force

which drops all tables, re-applies every migration, and gives you a clean database. The --force flag skips the confirmation prompt.

The Two-Process Problem

Here's the part that wasn't obvious.

Jest's globalSetup runs in a separate Node process from the test workers. The dotenv.config() call in e2e-setup.ts sets process.env.DATABASE_URL in that process. When the process exits, those env vars are gone.

The test workers — where your NestJS app actually boots — never see them. So ConfigModule.forRoot() reads from .env (the dev config), and your tests hit the dev database anyway.

The fix: a second file loaded via setupFiles, which runs inside each test worker:

// test/e2e-env-setup.ts
import * as dotenv from 'dotenv';

export default async function () {
    dotenv.config({
        path: '.env.test',
        override: true
    });
}

And the Jest config ties both together:

{
  "globalSetup": "./e2e-setup.ts",
  "setupFiles": ["./e2e-env-setup.ts"],
  "testRegex": ".*\\.e2e-spec\\.ts$",
  "transformIgnorePatterns": ["node_modules/(?!uuid)"]
}

globalSetup runs once — resets the database. setupFiles runs per worker — loads the right env vars. Two files because they run in different processes.

(The transformIgnorePatterns line is there because uuid ships ESM-only in newer versions, and Jest needs to transform it.)

E2e Tests Are User Flows, Not Isolated Units

One design question I had: does calling a membership endpoint inside an organization e2e test violate separation of concerns?

No — and this is an important distinction. Unit tests isolate. The org service test only tests the org service. But e2e tests verify user flows. A real user would:

Register an account
Create an organization
Check that they're the owner
That's one coherent scenario. The e2e test mirrors it:

describe('Register a user, create an org, verify OWNER membership', () => {
    it('POST /auth/register', async () => {
        await request(app.getHttpServer())
            .post('/api/v1/auth/register')
            .send({
                email: 'org-test@test.com',
                password: 'password123',
                displayName: 'E2E Org Test'
            })
            .expect(201)
            .expect((res) => {
                accessToken = res.body.data.accessToken;
            });
    });

    it('should create org and verify OWNER membership', async () => {
        const orgRes = await request(app.getHttpServer())
            .post('/api/v1/organizations')
            .set('Authorization', `Bearer ${accessToken}`)
            .send({ name: 'Test Org', description: 'E2E testing org.' });

        expect(orgRes.statusCode).toBe(201);

        const membership = await request(app.getHttpServer())
            .get(`/api/v1/organizations/${orgRes.body.data.id}/members/find`)
            .set('Authorization', `Bearer ${accessToken}`);

        expect(membership.body.data.role).toBe('OWNER');
    });
});

The create endpoint only returns the org — not the membership. So verifying OWNER requires a second request to the membership endpoint. That's not a test smell. That's the test doing what a user would do.

Takeaway

Unit tests and e2e tests aren't redundant — they catch different things. Unit tests prove your logic is correct. E2e tests prove your app actually works when a real HTTP request hits it. A missing decorator, a wrong status code, a misconfigured pipe — these are invisible to unit tests.

Set up both. Run both. Trust neither alone.

Week 1 Building RunHop: DDD Structure, JWT Auth, and a Race Condition I Didn't See Coming

Rhico — Thu, 26 Mar 2026 00:49:31 +0000

I'm building RunHop — a social platform for running races — as a way to go deep on the NestJS/TypeScript stack.

The goal from day 1 was to build it the way a real production system gets built: domain-driven structure, proper auth, test coverage from the start. Not a tutorial app.

Here's what the first week looked like.

Architecture First

Before writing a single line of app code, I mapped out the domain structure. RunHop has clear bounded contexts — identity (auth, users), organization (clubs, membership), event (races, registrations) — so the folder structure reflects that:

src/ domain/ identity/ organization/ event/ shared/

Each context gets its own module, services, controllers, and DTOs. No flat src/services/ folder that becomes a dumping ground by month two.

The Prisma schema covers the full data model upfront: User, Organization, OrgMembership, Event, EventRegistration. Designing it early forced me to think through the relationships before writing business logic — which fields are required, where the foreign keys go, what cascades on delete.

This matters at scale. When every feature you add has to figure out where it lives, you lose time on decisions that should already be made. DDD structure pays for itself fast.

The Logout Problem Everyone Ignores

JWTs are stateless — which sounds great until you realize it means you can't actually log someone out. Once a token is issued, it's valid until it expires. There's no server-side session to destroy.

Most tutorials skip this entirely. The token expires in 15 minutes, so who cares? In production, you care. Users expect logout to mean logout.

The fix: store refresh tokens in Redis. On login, the refresh token gets written to Redis with a TTL matching its expiration. On logout, delete it. When the client tries to use the refresh token to get a new access token, it's gone.

async logout(userId: string): Promise<void> {
  await this.redis.del(`refresh_token:${userId}`);
}

async refreshTokens(userId: string, refreshToken: string) {
  const stored = await this.redis.get(`refresh_token:${userId}`);
  if (!stored || stored !== refreshToken) {
    throw new UnauthorizedException('Invalid refresh token');
  }
  // Issue new token pair, rotate refresh token
}

Simple in concept. The access token still lives until it expires (short TTL), but the refresh token — the one that matters for persistence — is revocable.

The Race Condition
My E2E test was passing. It shouldn't have been.

The test flow: register → login → logout → try to use the refresh token → expect 401. Straightforward. But the logout step wasn't fully completing before the next request fired.

The problem was a missing await on the Redis del() call inside the logout handler. The function returned before Redis confirmed the deletion. Most of the time, Redis is fast enough that it didn't matter — the token was gone by the time the next request arrived. But "most of the time" isn't a test you can trust.

Once I added the await, the test became deterministic. It fails when it should fail.

Async timing bugs are the worst kind of test problem because they produce tests that pass — just not for the right reasons. If your test involves any async side effect, make sure every step is fully resolved before asserting.

Forem: Rhico

Why My Prisma P2002 Was Escaping try/catch in NestJS

The Service Looked Correct

The Rest of the Module

Takeaway

Why !false Broke My API: Building a Polymorphic Follow System in NestJS

The Module: Polymorphic Follows

The Bug: !false === true

Route Collisions in NestJS

E2E Testing Strategy

Takeaway

Prisma Errors Aren't All the Same: Building a Registration Module in NestJS

The Module

The Problem: Three Failure Modes

findUnique returns null

Status Filtering

Testing With Realistic Data

Takeaway

When a Passing Test Lies: Fixing an E2E False Positive in NestJS

The Bug: An E2E Test That Didn’t Test Updates

The Fix

The Other Bug: Non-Null Assertions Hiding 500s

The Fix

Why This Matters

Takeaway

A State Machine in 10 Lines: Event Status Transitions in NestJS

The Problem

The Implementation

The Date Format Gap

Cross-Field Validation

Extracting Shared Logic

E2E vs Unit: Know Which Assertion Style You're In

Takeaway

Mock What Prisma Returns, Not What Your API Returns

The Crash

Why This Happens

The Pagination Test That Compared a List to Itself

Membership E2E: Permission Boundaries

Takeaway

Why My Unit Tests Passed But My App Was Broken

The Bug Unit Tests Can't See

Setting Up a Dedicated Test Database

The Two-Process Problem

E2e Tests Are User Flows, Not Isolated Units

Takeaway

Week 1 Building RunHop: DDD Structure, JWT Auth, and a Race Condition I Didn't See Coming

Architecture First

The Logout Problem Everyone Ignores

The Bug: `!false === true`

`findUnique` returns `null`