[BUG] - Next.js Full Stack Web App Throws Exception to UI on Startup

[Sayvai]

Describe the bug
Occasionally (not all the time), whenever I start up the local frontend full stack Next.js webapp, and then attempt to load the frontend UI after the Next.js servers are up and ready, the browser displays an exception thrown by Next.js.

The exception which is occasionally thrown, throws with the error message Attempted to call getErrorMessage() from the server, but getErrorMessage is on the client. It's not possible to invoke a client function from the server, it can only be rendered as a Component or passed to props of a client component.. See screenshot of exception thrown on browser UI, below.

To Reproduce
Steps to reproduce the behavior:

1. Follow installation and configuration instructions from the README files on the root of the project, and inside the webapp. directory.
2. Open a terminal / shell
3. cd into the sub-directory webapp/
4. Run the command npm run dev to run both the frontend and backend servers concurrently under one terminal session locally.
5. Once both the frontend and backend servers ready, open the browser and navigate to http://localhost:3000/
6. You should see an exception message rendered on the UI

Expected behavior
The frontend UI should load correctly, initially prompting the user to upload a Resume / CV.

Screenshots

Exception message rendered on the frontend UI of the full stack Next.js web app.

Desktop (please complete the following information):

• OS: Mac OS Ventura 13.4
• Browser: Chrome
• Version: 118.0.5993.96

Additional context
💡 It seems that the error.ts file from which the getErrorMessage() function is defined conflicts with the reserved Next.js app router keyword for error.tsx components, and so Next.js (mistakenly) assumes error.ts is client component file, and hence why use client was placed at the top of the error.ts file in the first place to overcome the initial error. However, in hindsight this is not the correct solution as the function should be called on the server-side, and so the solution should be to instead rename error.ts to errors.ts, which also makes more logical sense, and can be extended with additional error handling functions in future.