The PENDING response solves the connection timeout, but it creates a second contract: how does a client distinguish work that is still running from work that was abandoned? A status row that remains pending indefinitely can be more confusing than the original failed request.

I would expose separate queued, running, completed, and failed states, with a last-progress timestamp and a documented expiry outcome. Test by stopping the worker after the initial response and again just before result publication. The poller should reach an honest terminal state in both cases, rather than depending on the browser staying open or treating elapsed time as evidence that the analysis succeeded.