Scanning an ID from a phone no longer gets stuck

At a recycling center, taking in waste from an individual requires identifying them: name, national ID number, address all go on the handover document, as required by the rules. The classic way is clunky: the operator manually reads the ID card and transcribes the data, with all the error risk that comes from transcribing under the pressure of a line of customers.

In VanaGreen, this step happens from a phone: the operator photographs the ID, and an OCR (optical character recognition) engine automatically reads the name, ID number, and address straight into the form. No dedicated scanner or extra device to maintain. The phone the operator already carries does the job.

What was actually broken

This feature had already gotten one fix recently. The OCR engine ran through an external library (tesseract.js) that downloaded its recognition files from a public CDN, and the server's security policy blocked those requests. The result was a silent failure, on every scan. We fixed that by hosting the engine fully locally, with no external network dependency, a firm decision for anything touching personal data like an ID card.

Once that step was fixed, a new, more subtle problem showed up: scanning worked, but could get stuck indefinitely on the "Reading data…" message. Not a displayed error, but a genuine screen freeze. Tested live, under deliberately unfavorable conditions (a landscape photo, taken quickly, without care for framing), the phone stayed stuck there, and the only fix was to close and restart the scan from scratch.

Why it happened

Two factors combined. First: a photo taken directly with the phone's camera is typically 3000-4000 pixels wide and several megabytes, far more than the recognition engine needs to read the text. With such a large photo, the engine (which runs entirely in the browser, via WebAssembly) could grind for much longer than normal, sometimes never finishing at all.

The second factor was the lack of a time cap. The app simply waited for the read operation to finish. If it never finished, the app never moved on either. There was no mechanism to say "that's enough waiting, let's move forward."

What changed

The fix has two parts, designed to work together. Before the photo reaches the recognition engine, the app now resizes it automatically, to a maximum of 1800 pixels on the long side, enough for the text to stay legible, but much faster to process. As a side benefit, resizing also corrects the photo's orientation (a sideways photo no longer reaches the reading engine with rotated pixels).

The second part is an explicit 20-second timeout: whatever happens with the actual recognition, the operator is guaranteed to reach the confirmation screen within 20 seconds of the scan. If the engine managed to read the data, it appears pre-filled; if not, the operator enters it manually, without having lost time staring at a frozen screen.

Why it matters for an operator

The difference isn't visible in big numbers. It's in how often it happens. Scanning an ID is a daily step, at every handover from an individual. An occasional freeze, even if fixable by retrying, means a line at the center, a frustrated operator, and, at the limit, the temptation to give up on scanning and go back to manual transcription, exactly what this feature was meant to eliminate.

With automatic resizing and the safety timeout, scanning from a phone becomes what it was supposed to be from the start: a fast, predictable step, regardless of how good or bad the photo taken in a hurry at the counter turns out to be.