TSA-282: [FE] Go straight to verification after Start processing

[IgnacioRB]

Closes #282
It will be on draft until PR #344 is merged into main branch. Ignore the backend files since hey belong to the backend counterpart #281.

Summary

Updated the document ingestion flow to navigate users directly from the upload screen to the verification workspace upon a successful POST /documents/:id/ingest call, eliminating unnecessary intermediate screens and extra clicks.

Previously, triggering process completion left the user on the document page where they had to watch a progress line and manually click "Resume at page 1" to begin working. Now, the user journey proceeds seamlessly into the verification view as soon as ingestion is completely successful with the first page. Also, if ingestion fails, the application redirects to the document page and clearly displays the failure reason.

Corresponding Redux slice reducers for ingest were wired up to correctly track state, and UI text anomalies during document preparation states were cleaned up.

Changes

• Once you are on the document-new page and start the ingestion, instead of redirecting you directly to the document page, it will stay there showing loading progress and automatically take you to the verification screen once ready.

• If ingestion fails and you are still on the document-new page, it will redirect you to the document page and display the error. If you navigate away while it's ingesting, you will access the document page instead manually to check if there is an error.

• Updated the preparation/waiting message on the verification screen to accurately state that pages are currently being prepared, instead of falsely claiming that everything has already been verified. If you are on a page that is still being processed, it will automatically update once the transcription is ready.

UI changes

• If the ingestion fails, the resulting error will be displayed in a box on the document page.

• Updated the preparation/waiting message on the verification workspace to accurately state that pages are currently being prepared, rather than falsely claiming that everything has already been verified.

[RomanNabukhotniidev]

Heads-up before this goes further: #414 (TSA-331) landed the same navigation on a different branch, as part of a batch of upload/ingest fixes. Sorry for the overlap — it wasn't scoped as TSA-282 work, so it wasn't obvious from the board.

What overlaps. Both PRs rewrite handleProcessDocument in document-new.tsx from the same base (2abbc72a), so they will conflict. Both end up navigating to AppRoute.VERIFICATION from the upload screen.

The mechanism differs:

• here: await dispatch(documentActions.ingest(id)).unwrap() → navigate when the POST resolves;
• in TSA-331 Readable transcription text on verification screen #414: poll the document and navigate when progress.pagesReadyToCheck > 0, with an ingest progress screen (pages ready / total) while waiting.

We went with polling because the navigation then doesn't depend on a long request staying alive — a timeout, a reconnect or a backgrounded tab would otherwise leave the user stranded on the upload screen. It also removes the need for the backend changes in this PR (and those belong to #281 anyway).

What is NOT covered by #414 and should stay in this PR:

1. The ingestion failure message. TSA-331 Readable transcription text on verification screen #414 only routes to the document page on DocumentStatus.FAILED — the user gets no explanation where they are standing. The error box from this PR is still the right behaviour.

2. PREPARING_DOCUMENTS vs EVERYTHING_VERIFIED on the verification screen. This one actually matters more now. TSA-331 Readable transcription text on verification screen #414 opens verification as soon as the first page is ready, so most users will land on a document where 1 of N pages is done — and today that screen claims everything has been verified. Before, people arrived late enough that the wrong copy was rarely seen.

Suggested next step: let #414 land, then rebase this on top and keep only (1) and (2) — dropping the navigation effect, the readyToVerifyId state and the backend files. TSA-282 itself is then satisfied by #414, and what's left here is really a separate copy/error-handling fix, so it may be cleaner as its own small PR against a new ticket.

[RomanNabukhotniidev]

Please review the new transition logic, remove the duplicate logic, and keep a few of your fixes.

[IgnacioRB]

@RomanNabukhotniidev Done! I cleaned up the overlapping transition logic, removed the duplicates, and kept the ingestion error handling and preparation message fixes as suggested. The backend files come from issue #281 which already has a PR, so once it merges into main, I will make sure they are no longer present in this PR. Thanks!

[RomanNabukhotniidev]

make it ready for review if it done

[IgnacioRB]

Hi @RomanNabukhotniidev, the PR is ready for review with all the changes suggested, now without the backend files.

[MatiStb]

I reviewed the branch against main: both of Roman's comments are properly resolved (the hasVerifiedPages signal and the setTimeout → setInterval change), but the four blocking items are still untouched. The worst one is that /verify fetches the document once and never refreshes it, so with a large PDF you end up with pageCount = 0 frozen, the cursor stuck on page 1, and a dead ► button. On top of that there's the 60 s timeout that dumps you back on the document page (the old flow with the extra click), the failed ingest that doesn't keep you on the upload screen with the reason, and the POST /ingest still not awaited, whose error nobody sees because the middleware swallows it. Short version: the new flow works fine on small documents, but it breaks on the large ones — which is exactly the case in the ticket

[MatiStb]

Resolve conflicts, please

[RomanNabukhotniidev]

@IgnacioRB @MatiStb I merged main in (one import conflict) and pushed three commits, since we were going in circles on this. Tested on a 3-page and a 120-page PDF.

The large-file problem is in the backend, not in this PR. page_count was only written at the very end of ingest, after every page had been cut. So on 120 pages /verify showed page 1 (processing...) for almost two minutes, ► was dead and Enter confirmed nothing. One line in document.service.ts now stores it right after pdfinfo. After that the header reads page 3 of 120 straight away and Enter works while the rest is still being split. It is a backend file in a frontend PR, but without it the flow does not work on the case the ticket is about.

The cursor jumped back. When ingest finished, the document reloaded and the cursor effect ran a second time, throwing the user from page 3 back to page 1. Now the cursor is initialised once per document.

Mati's two other points are fixed: a failed ingest keeps you on the upload screen with the real reason ("Failed to read PDF. It may be corrupted"), and POST /ingest is awaited so a rejected request shows its message instead of being swallowed.

The 60 s timeout Ignacio was right about. Once page_count lands early the redirect happens in about 2 s, so it never fires. Left as is.

npm run lint and npm run build pass at the repo root. Please re-check on your side.

[RomanNabukhotniidev]

Merged main in and pushed the four fixes myself, then retested on a 3-page and a 120-page PDF: the verification screen opens with a real page count straight away, the cursor no longer jumps back when ingest finishes, and a failed ingest keeps the user on the upload screen with the actual reason. Lint and build are green.

@MatiStb your changes-requested is still standing and blocks the merge, please take another look when you can.

[IgnacioRB]

Hi, I’ve reviewed @MatiStb’s comments and @RomanNabukhotniidev’s changes. Thanks a lot for the backend adjustment to save the page_count from the start and for the cursor fix; those perfectly complement the solution. I’ve checked everything over; regarding the requirement to stay on the upload screen when an ingestion error occurs, I believe Mati also meant cases where an error happens during the ingestion process. So, I took the liberty of adding logic to ensure that if an ingestion error occurs during the process, the process remains on the upload screen—displaying the actual reason for the failure—instead of redirecting the user to the document page. That’s the only addition I made in my commit d022a85; everything else should be working fine. Everything passes the linter and build checks correctly on my end.