Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: handle phone numbers as strings #1344

Merged
merged 5 commits into from
Mar 1, 2025
Merged

Conversation

Nuel-MD
Copy link
Contributor

@Nuel-MD Nuel-MD commented Mar 1, 2025

Pull Request

Description

This PR resolves an issue where the /api/v1/contact endpoint fails to handle phone numbers correctly when sent as strings, due to the backend or database schema expecting integers. The changes include:

  • Updated the phone field in the ContactUs entity to use string instead of number.
  • Created a migration to alter the phone column in the contact_us table to VARCHAR(20).
  • Updated the CreateContactDto to accept and validate phone as a string, including proper validation for phone number formats.
  • Ensured existing integer data is safely converted to strings during the migration to prevent data loss or errors.

These changes ensure the endpoint can handle valid phone numbers (e.g., "08098363636" or "+2348034567890") without internal server errors, improving user experience and backend stability.

Related Issue

Fixes #1252

Type of Change

  • feat: New feature
  • fix: Bug fix
  • docs: Documentation updates
  • style: Code style/formatting changes
  • refactor: Code refactoring
  • perf: Performance improvements
  • test: Test additions/updates
  • chore: Build process or tooling changes
  • ci: CI configuration changes
  • other:

How Has This Been Tested?

  • Unit tests
  • Integration tests
  • Manual tests

Test Evidence

  • Sending a POST request to /api/v1/contact with a phone number as a string (e.g., "08040234966" and "+2348034567890") using Postman.
  • Verifying that the phone number is stored correctly in the database as a string in the contact_us table.
  • Confirming the API returns a 201 Created response with no errors.
  • Checking that existing integer phone numbers are converted safely during the migration.

Screenshots (if applicable)

image

Checklist

  • My code follows the project's coding style
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes
  • Any dependent changes have been merged and published
  • I have included a screenshot showing all tests passing
  • I have included documentation screenshots (if applicable)

Additional Notes

  • The migration ensures backward compatibility by safely converting existing integer phone numbers to strings using phone::text in PostgreSQL.
  • I tested edge cases, including phone numbers with leading zeros (e.g., "08098363636") and international formats (e.g., "+2348034567890"), and confirmed they are handled correctly.
  • The changes maintain consistency with the HNG boilerplate’s API response structure: {"status": "success", "status_code": 201, "message": "Contact created successfully", "data": {}}.

Emmanuel Muogbo and others added 4 commits March 1, 2025 11:45
… use string for phone- Created migration to alter phone column to VARCHAR(20)- Updated DTO to accept and validate phone as string- Ensured existing integer data is converted safely
fix: change phone number storage to string
@theblvckdev
Copy link
Contributor

update your branch @Nuel-MD

@Nuel-MD
Copy link
Contributor Author

Nuel-MD commented Mar 1, 2025

done!

@theblvckdev theblvckdev merged commit bdf6865 into hngprojects:dev Mar 1, 2025
1 check 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.

[FIX] Eliminate internal server error via user input in Contact Us Page
2 participants