fix: implement proper job status polling for audio processing

[NotYuSheng]

Summary

This PR implements robust job status polling for audio processing, ensuring reliable handling of long-running transcription tasks with proper error handling and timeout management.

---

Changes Made

• Implement comprehensive job status polling mechanism
• Add proper error handling for failed processing jobs
• Include timeout management to prevent infinite polling
• Enhanced user feedback during processing with status updates
• Reliable transcript retrieval after job completion
• Improved async/await pattern for better error propagation

---

Context / Rationale

The previous audio processing workflow lacked proper job polling, causing issues with:

1. Long audio files that require extended processing time
2. No feedback during processing, leading to user confusion
3. Failed jobs not being handled gracefully
4. Unreliable transcript retrieval after processing completion

This implementation provides:

• Reliability: Proper polling ensures no lost jobs
• User Experience: Clear feedback during processing
• Error Handling: Graceful handling of failed jobs
• Timeout Protection: Prevents infinite waiting

---

Related Docs or References

• Addresses asynchronous job processing requirements
• Improves reliability of audio transcription workflow

---

FastAPI Application Checklist (Delete if PR is not relevant)

• Long-running operations support both job polling (e.g., via /status/{job_id} or /progress/{job_id}) and optional webhooks (if a callback_url is provided).
  • If callback_url is not provided, the client can retrieve status and results via polling endpoints.
• Job results are persisted or recoverable if needed

---

General Checklist

• I have tested these changes locally
• I have updated relevant documentation or added comments where needed
• I have linked relevant issues and tagged reviewers
• I have followed coding conventions and naming standards

[gemini-code-assist]

Summary of Changes

Hello @NotYuSheng, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the reliability and user experience of the audio processing workflow by introducing robust job status polling on the frontend. Concurrently, it modernizes the frontend deployment by transitioning to an Nginx-based serving architecture, improving performance and maintainability. The changes also include a comprehensive visual overhaul to provide a more polished and intuitive interface.

Highlights

• Robust Audio Processing Polling: Implemented a comprehensive job status polling mechanism for audio processing, ensuring reliable handling of long-running transcription tasks. This includes proper error handling, timeout management, and enhanced user feedback during processing.
• Frontend Architecture Shift to Nginx: The frontend Docker setup has been significantly refactored from a Node.js development server to a production-ready Nginx static file server. This involves a multi-stage Dockerfile, a new nginx.conf for serving React assets and proxying API requests, and updated Docker Compose configurations.
• Enhanced User Experience for Audio Input: Introduced new UI controls for recording (start, pause, resume, stop), uploading, and processing audio. Users can now preview recorded or uploaded audio before processing, and there are dedicated buttons to discard recordings or uploads. The recording indicator now also shows a 'paused' state.
• Visual and Theming Improvements: The application's CSS has undergone a substantial refresh, introducing new color variables, gradients for backgrounds and buttons, and improved styling for cards, buttons (including new discrete action buttons), and the dark mode toggle. The background particles animation colors have also been updated.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments or fill out our survey to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a robust job status polling mechanism for audio processing, significantly improving the handling of long-running transcription tasks. The changes are well-structured, especially the move to async/await with try/catch blocks for better error handling and the major UI/UX enhancements for the recording and file upload flow.

My review focuses on a few key areas to further improve the implementation:

• Configuration: Hardcoded polling parameters could be made more flexible.
• Robustness: There's a potential logic gap in the polling function that could lead to misleading errors.
• User Experience: Replacing alert() with in-app notifications would improve the user experience.
• Best Practices: I've also included some suggestions regarding Docker and CSS best practices.

Overall, this is a strong contribution that makes the application much more reliable and user-friendly. Addressing the points below will help solidify this excellent work.

[gemini-code-assist]

The polling parameters are hardcoded here (maxAttempts = 30) and within the setTimeout on line 411 (2000ms). This results in a fixed 60-second timeout, which may be insufficient for processing long audio files and could lead to a poor user experience if jobs appear to fail prematurely.

These values should be more flexible. Consider defining them as constants at the top of the file for easier configuration.

[gemini-code-assist]

There's a potential logic issue here. If the job status is 'completed' but transcriptData.full_transcript is not present in the response, the function will not return or throw. Instead, it will continue polling until it hits maxAttempts and then throw a misleading timeout error. You should handle this case explicitly by throwing an error if the transcript is missing after a job is marked as complete.

Suggested change

	if (transcriptData.full_transcript) {
	const parsed = JSON.parse(transcriptData.full_transcript || "[]");
	setTranscript(processTranscriptWithSpeakerIds(parsed));
	setSelectedMeetingId(uuid);
	fetchSummary(uuid);
	fetchMeetingList();
	return true;
	}
	if (transcriptData.full_transcript) {
	const parsed = JSON.parse(transcriptData.full_transcript || "[]");
	setTranscript(processTranscriptWithSpeakerIds(parsed));
	setSelectedMeetingId(uuid);
	fetchSummary(uuid);
	fetchMeetingList();
	return true;
	} else {
	throw new Error('Job completed, but transcript data is missing.');
	}

[gemini-code-assist]

Using --only=production in a builder stage is unconventional. Build-time dependencies (like bundlers or test runners) are typically in devDependencies, and a build stage needs them. While this works for your current package.json setup where react-scripts is a production dependency, it's brittle and goes against standard practice.

For a builder stage, it's safer to install all dependencies to ensure the build process is robust.

RUN npm ci

[gemini-code-assist]

The use of !important should be avoided as it breaks the natural CSS cascade and can make stylesheets difficult to maintain and debug. It's often a sign that the selector's specificity needs to be adjusted.

This comment also applies to other instances of !important in this file (e.g., lines 189, 194, 206, 214).

[gemini-code-assist]

Using window.alert() for error messages provides a poor user experience as it's a blocking and intrusive system dialog. This also occurs on line 496. It would be better to display errors gracefully within the application's UI, for example by using a state variable to hold the error message and rendering it in a dedicated component.