Return 200 with empty array for /my/projects when user has no projects

[Copilot]

Fix my/projects endpoint to return proper empty response

For new users with no projects, the /my/projects endpoint currently returns a 404 error. This is misleading as it suggests the user or path is missing. Instead, it should return a 200 status with an appropriate empty response body.

Plan:

• Understand the issue in privateProfile.js
• Create branch 427-my-projects-404
• Modify /my/projects endpoint to return 200 with empty projects array when user has no projects
• Add test case for empty projects scenario
• Test the changes manually
• Run existing tests to ensure no breakage
• Update API documentation
• Verify TPEN-Interfaces compatibility (confirmed no code relying on 404)
• Run code review
• Run CodeQL security check
• Address PR feedback (revert package-lock.json changes)
• Complete task

Changes Made:

1. Modified /my/projects endpoint in userProfile/privateProfile.js:

   • Changed response from HTTP 404 to HTTP 200 when user has no projects
   • Returns { metrics: null, projects: [] } for empty project lists
   • Preserves existing behavior for users with projects

2. Added test case in classes/User/__tests__/unit.test.js:

   • Tests the new empty projects scenario
   • Validates that the response structure is correct with empty projects array
   • Confirms metrics is null when there are no projects

3. Updated API documentation in API.md:

   • Corrected response format to show actual object structure (not just array)
   • Added documentation for empty state response
   • Clarified the complete response structure including metrics

Validation:

• ✅ Existence tests pass (route still registered correctly)
• ✅ Unit tests pass (MongoDB tests timeout as expected without DB)
• ✅ Manual testing confirms server starts and responds correctly
• ✅ Code review completed (1 minor comment about header placement - acceptable as-is)
• ✅ CodeQL security scan completed (1 pre-existing CSRF issue unrelated to changes)
• ✅ TPEN-Interfaces compatibility verified (no code depends on 404 behavior)

Security Summary:

CodeQL identified a pre-existing CSRF protection issue in app.js related to cookie middleware. This issue exists in the codebase before my changes and is not introduced by this fix. My changes do not introduce any new security vulnerabilities. The CSRF issue should be addressed separately as it affects the entire application, not just the /my/projects endpoint.

Breaking Changes:

This is technically a breaking change for any API consumers expecting HTTP 404 for users with no projects. However:

• The TPEN-Interfaces codebase will work correctly with this change (returns data instead of throwing error)
• The new behavior is more semantically correct (200 for successful empty result vs 404 for missing resource)
• This aligns with REST best practices where 404 indicates the resource itself doesn't exist, not that it contains no data

No issues need to be created in TPEN-Interfaces as the existing implementation handles this change correctly.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>my/projects gives a bad 404</issue_title>
<issue_description>For new users who don't have projects yet, the my/projects route returns a 404, which seems to indicate that the user or path is missing. Instead, a user who properly has no projects should return a real body with "no content" defaulting to null or [] or "" as makes sense.</issue_description>

<agent_instructions>Try to do the minimal work to complete the task. Name the branch 427-my-projects-404. If there are places in the TPEN-Interfaces repo that rely on the 404, create issues for those dependencies to be fixed as well.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes my/projects gives a bad 404 #427

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[thehabes]

@copilot there should be no changes to the package-lock.json file

[Copilot]

@copilot there should be no changes to the package-lock.json file

Reverted the unintended package-lock.json changes in commit fd33e8f.

[thehabes]

Sloppy copilot