Skip to content

fix: remove ambiguous numeric 'id' from Employee type - #81

Merged
Senthil455 merged 1 commit into
Senthil455:mainfrom
DivyashreeR008:fix/employee-type-id-ambiguity
Jun 17, 2026
Merged

fix: remove ambiguous numeric 'id' from Employee type#81
Senthil455 merged 1 commit into
Senthil455:mainfrom
DivyashreeR008:fix/employee-type-id-ambiguity

Conversation

@DivyashreeR008

Copy link
Copy Markdown
Collaborator

Summary

The \Employee\ type in \ rontend/src/types/index.ts\ had both _id\ (MongoDB string) and \id\ (number) declared as optional fields, creating ambiguity about which identifier to use in API calls (#62).

Changes

  • *Removed \id?: number* — This numeric ID has no backend counterpart. The \employee-python-service\ model uses MongoDB ObjectId (_id) and the Pydantic schema aliases it to \id\ as a string, not a number. The field was never referenced anywhere in frontend code.
  • *Kept _id?: string* — The backend returns the MongoDB ObjectId as a string in all API responses. It remains optional to accommodate creation scenarios where _id\ is assigned by the database.

Context

All employee CRUD API routes (\GET, \PUT, \DELETE) use \email\ as the unique lookup key. Neither _id\ nor the removed numeric \id\ is passed to any API endpoint. The effective identifier throughout the codebase is \email.

Verification

  • \grep\ across \ rontend/src\ confirmed zero usages of \employee.id\ or \emp.id\
  • Backend \employee-python-service/main.py\ confirmed no numeric \id\ field exists
  • Existing tests pass without changes needed

The Employee type had both _id (MongoDB string) and id (number) as
optional fields, creating ambiguity about which identifier to use.

- Remove id?: number — has no backend counterpart and is never used
- Keep _id?: string — the backend returns MongoDB ObjectId as string,
  kept optional for creation scenarios where _id is not yet assigned

The actual unique identifier used throughout the codebase is email,
which all CRUD API routes use as the lookup key.

@Senthil455 Senthil455 left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes
etwork: external: true to driver: bridge in docker-compose.monitoring.yml.

This looks good — external: true requires the network to already exist, which can cause startup failures in fresh environments. Using driver: bridge lets Docker Compose create it automatically. No issues found, ready to merge.

@DivyashreeR008

Copy link
Copy Markdown
Collaborator Author

Thank you for the review! No additional changes needed — merging as-is.

@Senthil455
Senthil455 merged commit 9be4b10 into Senthil455:main Jun 17, 2026
19 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants