feat: Implement Create Application Flow for User Onboarding

[AnujChhikara]

Date: 10 Jan 2026

Developer Name: @AnujChhikara

---

Issue Ticket Number

• feat: modify create application API and update DB schema for application #2532

Description

This PR implements the create application flow for the onboarding revamp, introducing role-based applications, migration support for existing pending applications, and enhanced validation.

Documentation Updated?

• Yes
• No

Under Feature Flag

• Yes
• No

Database Changes

• Yes
• No

Breaking Changes

• Yes
• No

Development Tested?

• Yes
• No

Screenshots

Screenshot 1

• For new user successfully creating

• screen-recording-2026-01-13-at-110213-am_LHykvFuR.mp4
• 

• For old user who have application before 1 Jan 2026

already-exist.mp4

Test Coverage

Screenshot 1

Additional Notes

[coderabbitai]

Walkthrough

This PR extends the application system with role-based applications, social link support, and image URLs. A new service layer handles application creation and updates, distinguishing between new applications and migrated ones through status codes and response messages.

Changes

Cohort / File(s)	Summary
Constants Restructuring constants/application.ts	Converted APPLICATION_STATUS_TYPES from array to object with uppercase keys; added CHANGES_REQUESTED status; introduced new APPLICATION_ROLES enum; added application success messages (APPLICATION_CREATED_SUCCESS, APPLICATION_UPDATED_SUCCESS) and new error messages object (APPLICATION_ERROR_MESSAGES).
Type Definitions types/application.d.ts	Added new types: ApplicationRole, SocialLink, and feedback. Expanded application type with optional fields: role, isNew, imageUrl, nudgeCount, lastNudgeAt, migratedAt, lastEditAt, socialLink, score, and feedback[]. Extended applicationPayload with required role and optional imageUrl, socialLink, and answers.
Application Service services/applicationService.ts	Introduced new createApplicationService handling application creation and updates. Checks existing applications; throws Conflict if migrated; updates PENDING applications with reset score; creates new applications with PENDING status. Returns applicationId, isNew, and migratedAt fields.
Data Access models/applications.ts	Added new getApplicationByUserId(userId: string) function to query existing applications by user ID.
Controller Logic controllers/applications.ts	Replaced direct application object construction with createApplicationService call. Updated response handling: 201 with APPLICATION_CREATED_SUCCESS for new applications, 200 with APPLICATION_UPDATED_SUCCESS for updates. Added 409 Conflict error handling. Updated logging to include applicationId and isNew metadata.
Validation middlewares/validators/application.ts	Added schema validation for new fields: role (required, from APPLICATION_ROLES), imageUrl (optional URI), and socialLink (optional nested object with phoneNo, github, instagram, linkedin, twitter, peerlist, behance, dribble). Updated status validation to use Object.values(APPLICATION_STATUS_TYPES).
Test Fixtures & Integration Tests test/fixtures/applications/applications.ts, test/integration/application.test.ts	Added role: "developer" property to fixture objects. Updated integration tests to expect new response messages, status codes (201 for creation, 200 for updates), and applicationId in responses. Added test scenario for pre-2026-01-01 application updates.

Sequence Diagram

sequenceDiagram
    participant Client
    participant Controller
    participant Service
    participant Model
    participant Database

    Client->>Controller: POST /applications (with role, imageUrl, socialLink)
    Controller->>Service: createApplicationService({userId, payload})
    Service->>Model: getApplicationByUserId(userId)
    Model->>Database: Query ApplicationsModel by userId
    Database-->>Model: Return existing app or null
    Model-->>Service: Application record or null

    alt Existing application after 2026-01-01
        Service-->>Controller: Throw Conflict (ALREADY_REVIEWED)
    else Existing PENDING application (before 2026-01-01)
        Service->>Database: Update application with transformed payload
        Database-->>Service: Updated record
        Service-->>Controller: {applicationId, isNew: true, migratedAt}
        Controller->>Controller: Log with applicationId and isNew
        Controller-->>Client: 200 APPLICATION_UPDATED_SUCCESS
    else No existing application
        Service->>Database: Create new application (status: PENDING)
        Database-->>Service: New application record
        Service-->>Controller: {applicationId, isNew: true}
        Controller->>Controller: Log with applicationId and isNew
        Controller-->>Client: 201 APPLICATION_CREATED_SUCCESS
    end

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Poem

🐰 New roles bloom, social links take flight,
Applications transform from day to night,
Create or migrate, the service decides with care,
Conflict and success both handled fair! 🌟

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely summarizes the main change: implementing a create application flow for user onboarding, which is the primary objective of the PR.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description check	✅ Passed	The pull request description clearly describes the implementation of a create application flow for onboarding revamp with role-based applications and migration support.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 10

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

test/fixtures/applications/applications.ts (1)

1-162: LGTM!

The role: "developer" field is correctly added to all fixture objects, aligning with the new required field in the application schema.

Consider using varied roles across fixtures (e.g., "designer", "product_manager") to improve test coverage for role-specific behaviors.

🤖 Fix all issues with AI agents

In @constants/application.ts:
- Around line 21-25: The duplicate key APPLICATION_ALREADY_REVIEWED appears in
API_RESPONSE_MESSAGES and APPLICATION_ERROR_MESSAGES with different text;
consolidate by keeping a single canonical message or renaming one key to make
intent explicit (e.g., APPLICATION_ALREADY_REVIEWED_ERROR or
APPLICATION_ALREADY_REVIEWED_RESPONSE), update all usages to reference the
chosen symbol, or remove the API_RESPONSE_MESSAGES entry if it’s unused; ensure
you only change the key or value in API_RESPONSE_MESSAGES /
APPLICATION_ERROR_MESSAGES and update any references to those constants
accordingly.

In @middlewares/validators/application.ts:
- Around line 9-20: The socialLinkSchema object has a typo: the field "dribble"
should be "dribbble"; update the schema definition inside socialLinkSchema to
rename the key from dribble to dribbble (preserving
joi.string().uri().optional()) so incoming payloads for Dribbble are validated
correctly.
- Line 11: The phoneNo schema currently allows any string (phoneNo:
joi.string().optional()); tighten validation by adding either a regex pattern
for E.164 (e.g., /^\+?[1-9]\d{1,14}$/) or by applying length constraints via
.min()/.max(), and update the joi rule for the phoneNo field in the validator so
invalid phone numbers are rejected and valid formats are enforced.

In @models/applications.ts:
- Around line 119-136: getApplicationByUserId returns the first arbitrary
document because it lacks an ordering; modify the query on ApplicationsModel
(the call inside getApplicationByUserId) to order by "createdAt" descending and
limit the result to 1 (same behavior as getUserApplications) so you consistently
return the latest application for a user; update the
ApplicationsModel.where(...).get() call to include orderBy("createdAt", "desc")
and limit(1) before .get().

In @services/applicationService.ts:
- Around line 76-80: The code compares ISO strings which is brittle; convert the
sentinel "2026-01-01T00:00:00.000Z" to a Date and ensure
existingApplication.createdAt is compared as a Date/number (e.g., new
Date(januaryFirst2026) and existingApplication.createdAt instanceof Date ?
existingApplication.createdAt.getTime() : new
Date(existingApplication.createdAt).getTime()), then compare timestamps before
throwing Conflict(APPLICATION_ERROR_MESSAGES.APPLICATION_ALREADY_REVIEWED);
update the januaryFirst2026 symbol to hold a Date (or a numeric timestamp) and
use createdAt parsing/validation to avoid string comparisons.
- Around line 75-103: The current branch allows creating a new application when
an existing application was created before the 2026 cutoff but has a final
status (e.g., ACCEPTED/REJECTED), causing duplicates; update the logic in the
existingApplication handling (the block using existingApplication,
APPLICATION_STATUS_TYPES, and
APPLICATION_ERROR_MESSAGES.APPLICATION_ALREADY_REVIEWED) to explicitly block
creating a new application for non-PENDING statuses—after the createdAt check,
add a guard that if existingApplication.status !==
APPLICATION_STATUS_TYPES.PENDING (or is in [ACCEPTED, REJECTED]) then throw new
Conflict(APPLICATION_ERROR_MESSAGES.APPLICATION_ALREADY_REVIEWED) so only
PENDING records proceed to the migrate/update path that calls
transformPayloadToApplication and ApplicationModel.updateApplication.

In @test/integration/application.test.ts:
- Around line 356-372: The test is flaky because leftover applications persist
between tests; add an afterEach hook in the same describe block in
application.test.ts that cleans up test users' applications (e.g., await
applicationModel.deleteApplicationsByUserId(secondUserId) and the other test
user id) or alternatively generate and use a unique user id per test, and ensure
the cleanup awaits completion before proceeding to the next test so
getApplicationByUserId() returns deterministic results.

In @types/application.d.ts:
- Around line 78-81: The answers property currently uses a loose Record<string,
any> which reduces type safety; replace it with a more specific type (e.g.,
define an ApplicationAnswers interface or type alias that models expected
question keys and answer shapes, or use Record<string, string | number | boolean
| string[]> if answers are simple) and update the answers declaration to that
type (replace Record<string, any> with ApplicationAnswers or the chosen alias)
and then update any usages/tests to conform to the new shape to catch mismatches
at compile time.
- Around line 9-18: The SocialLink type has a typo: rename the field dribble to
dribbble within the SocialLink type definition and update all references/usages
of SocialLink across the codebase (imports, destructuring, mapping, tests,
serializers/deserializers, and any JSON keys) to use the new name; ensure
backward compatibility where necessary by migrating input/output mappings or
adding a temporary alias conversion from dribble to dribbble in places that
consume external data.
- Around line 20-25: Rename the exported type declaration named "feedback" to
use PascalCase ("Feedback") and update all references to it throughout the
codebase (including the usage currently referencing `feedback` on the other
declaration). Ensure the export name is updated to "Feedback" and fix any
imports/usages, type annotations, generics, or unions that refer to `feedback`
so they now reference `Feedback`, and run TypeScript to catch remaining spots.

📜 Review details

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 46ff1bb and b8d1488.

📒 Files selected for processing (8)

• constants/application.ts
• controllers/applications.ts
• middlewares/validators/application.ts
• models/applications.ts
• services/applicationService.ts
• test/fixtures/applications/applications.ts
• test/integration/application.test.ts
• types/application.d.ts

🧰 Additional context used

🧬 Code graph analysis (2)

services/applicationService.ts (2)

test/integration/discordactions.test.js (1)

• ApplicationModel (11-11)

types/application.d.ts (2)

• applicationPayload (64-82)
• application (27-62)

controllers/applications.ts (1)

services/applicationService.ts (1)

• createApplicationService (67-129)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

• GitHub Check: build (22.10.0)
• GitHub Check: Analyze (javascript)

🔇 Additional comments (10)

middlewares/validators/application.ts (2)

50-55: LGTM!

Role validation correctly uses Object.values(APPLICATION_ROLES) to ensure only valid roles are accepted. The imageUrl and socialLink validations are appropriately optional with proper URI validation.

---

76-81: LGTM!

The status validation correctly uses Object.values(APPLICATION_STATUS_TYPES).includes(value) to align with the refactored object-based constants.

controllers/applications.ts (1)

67-109: LGTM!

Good refactoring to use the service layer. The response handling correctly differentiates between new applications (201) and migrated ones (200). Error handling properly catches Conflict errors and returns appropriate 409 responses.

test/integration/application.test.ts (1)

349-352: LGTM!

Test expectations correctly verify the new response format with applicationId and appropriate messages for the creation flow.

services/applicationService.ts (2)

18-54: LGTM!

Clean transformation logic that properly maps the flat payload structure to the nested application model. Optional fields are handled correctly.

---

107-114: This type assertion is appropriate and all required fields are properly initialized.

The transformPayloadToApplication function explicitly returns Partial<application> and includes all required fields (userId, biodata, location, professional, intro, foundFrom). The object literal then provides additional fields (score, status, createdAt, isNew, nudgeCount). The as application cast is justified because the resulting object satisfies the complete application type contract.

Likely an incorrect or invalid review comment.

constants/application.ts (2)

1-6: LGTM!

Good refactoring from array to object for APPLICATION_STATUS_TYPES. This provides better type safety and allows for cleaner code when referencing specific statuses.

---

8-15: LGTM!

Well-defined role constants with consistent naming. Consider adding TypeScript type exports for better type inference across the codebase.

types/application.d.ts (2)

52-61: LGTM with minor note.

The new optional fields appropriately extend the application type to support role-based applications, social links, and migration tracking. The use of the newly defined ApplicationRole and SocialLink types ensures type safety.

Note: The feedback type reference on line 61 should be updated to Feedback once the naming convention issue is resolved (already flagged separately).

---

1-7: No action needed. The ApplicationRole type values already align perfectly with the APPLICATION_ROLES constant in constants/application.ts. All six role strings ("developer", "designer", "product_manager", "project_manager", "qa", "social_media") match exactly between the type definition and the constant values.