csv-xmlConduct full UX architecture review

[daler91]

No description provided.

[gemini-code-assist]

Code Review

This pull request significantly expands the project by adding a full-stack web application and a FastAPI-based worker service, enabling browser-based file uploads, column mapping, and conversion history. The changes include Docker configuration, comprehensive UX documentation, and enhanced Python converters. Feedback highlights critical areas for improvement, specifically addressing security risks associated with client-side status updates and potential race conditions during job state transitions. Recommendations also include adopting a more robust background task management system and refining the frontend ETA logic to handle page refreshes correctly.

[gemini-code-assist]

Allowing the client to update the status field directly via a PATCH request is a security risk. A malicious user could manually set a job's status to complete or error without the conversion actually taking place. Status transitions should be strictly controlled by the server-side logic (e.g., in the /start or /cancel routes). If the client needs to signal a state change (like mapping), it should be validated against a set of allowed transitions.

[gemini-code-assist]

Using prisma.job.update here introduces a race condition. If the conversion worker finishes and updates the status to complete between the check at line 38 and the update at line 45, the complete status will be overwritten by cancelled. Use updateMany with a status check in the where clause to ensure the update only occurs if the job is still in a cancellable state.

    await prisma.job.updateMany({
      where: {
        id: jobId,
        status: { in: ["converting", "uploaded", "previewed", "mapping"] }
      },
      data: { status: "cancelled", completedAt: new Date() },
    });

[gemini-code-assist]

Similar to the cancellation logic, using an unconditional update to set the status to converting can lead to race conditions or unintended re-runs of already completed jobs. It is safer to use updateMany and verify that the current status is one that allows starting a conversion (e.g., uploaded, previewed, or error).

    const updated = await prisma.job.updateMany({
      where: {
        id: jobId,
        status: { in: ["uploaded", "previewed", "mapping", "error"] }
      },
      data: { status: "converting" },
    });

    if (updated.count === 0) {
      return NextResponse.json({ error: "Job cannot be started in its current state" }, { status: 400 });
    }

[gemini-code-assist]

The background task started here via .then() is not robust. In a standalone Node.js server, this may continue to run, but if the process crashes or restarts (e.g., during a deployment), the task is lost and the job will remain stuck in the converting state indefinitely. For production reliability, consider using a persistent job queue (like BullMQ or a database-backed worker) to handle long-running conversions.

[gemini-code-assist]

The ETA calculation processed / elapsedMs assumes the conversion started exactly when the user loaded the page. If the user refreshes the page while a conversion is at 90%, elapsedMs resets to 0, causing the rate to be artificially high and the ETA to be wildly inaccurate. The calculation should ideally use a persistent start timestamp from the server (e.g., the job's updatedAt when it first transitioned to converting).