You are a senior software engineer taking over an existing d...

Prompt

You are a senior software engineer taking over an existing desktop video-processing application. The app is built with Electron, React and TypeScript. Video processing is done locally with FFmpeg. Do not redesign the application from scratch: modify the existing architecture with the smallest sensible set of changes. The app currently has an "Export Video" feature with several problems: 1. File paths containing spaces or special characters sometimes make FFmpeg fail. 2. Clicking Export twice can launch two FFmpeg processes simultaneously. 3. The Cancel button updates the UI but the FFmpeg process keeps running in the background. 4. Export progress is calculated against a hardcoded 30-second duration, so it is wrong for most videos. 5. When replacing the video's audio track, the output sometimes continues after the video ends. 6. FFmpeg errors are currently returned to the renderer as generic "Export failed" messages, making debugging difficult. Current simplified implementation: --- electron/main.ts --- import { ipcMain } from "electron"; import { exec } from "child_process"; ipcMain.handle("export-video", async (_event, options) => { const { inputPath, audioPath, outputPath } = options; const command = `ffmpeg -i ${inputPath} -i ${audioPath} ` + `-map 0:v -map 1:a -c:v copy -c:a aac ${outputPath}`; return new Promise((resolve, reject) => { const process = exec(command); process.stderr?.on("data", (data) => { const match = data.toString().match(/time=(\d+):(\d+):([\d.]+)/); if (match) { const seconds = Number(match[1]) * 3600 + Number(match[2]) * 60 + Number(match[3]); const progress = seconds / 30; // assume sendProgress() forwards progress to renderer sendProgress(progress); } }); process.on("close", (code) => { if (code === 0) resolve({ success: true }); else reject(new Error("Export failed")); }); }); }); ipcMain.handle("cancel-export", async () => { return { cancelled: true }; }); --- renderer/ExportPanel.tsx --- const [exporting, setExporting] = useState(false); const [progress, setProgress] = useState(0); async function exportVideo() { setExporting(true); try { await window.api.exportVideo({ inputPath, audioPath, outputPath }); } catch { alert("Export failed"); } setExporting(false); } async function cancelExport() { await window.api.cancelExport(); setExporting(false); } TASK Fix the implementation while keeping the architecture simple. Requirements: - Never construct FFmpeg commands by concatenating a shell command string. - Use an API that passes arguments separately to the FFmpeg executable. - File paths containing spaces, unicode or shell-special characters must work safely. - Determine the real source-video duration instead of assuming 30 seconds. - Use ffprobe or another appropriate FFmpeg mechanism to obtain duration. - Progress should be normalized between 0 and 1. - Only one export may run at a time. - The renderer must not be able to accidentally start concurrent exports. - Cancel must terminate the actual running FFmpeg process. - Cancellation must be distinguishable from a genuine FFmpeg failure. - Replacing audio must preserve the original video stream without re-encoding it. - The output must end when the shortest relevant input ends. - Return useful FFmpeg errors to the renderer without exposing unnecessary internal information. - Correctly clean up process references and listeners after success, failure or cancellation. - Consider macOS and Windows. - Do not introduce unnecessary dependencies. Before writing code, briefly identify the architectural problems in the existing implementation. Then provide: 1. Your implementation plan. 2. The corrected TypeScript implementation for the Electron main process. 3. The required renderer changes. 4. Any preload/API changes required. 5. A short test plan covering normal export, paths with spaces, concurrent export attempts, FFmpeg failure and cancellation. Important: Do not merely describe what should be changed. Provide implementable code. Do not replace Electron, React or FFmpeg with another technology. Prefer a small robust solution over a large abstraction. If you make an assumption, state it explicitly. At the end, include a section called "Potential remaining risks" containing only genuine issues that cannot be guaranteed from the information provided.