Can not compile invoices pdf

[nicolasVr]

Description

On French Instance compilation of invoices pdf doesn't work in some cases. The problem doesn't appear when printing from order page.

Expected Behavior

When required pdf should be generated.

Actual Behaviour

Only waiting screen is displayed

Steps to Reproduce

Using Firefox 123.0 (Ubuntu), I ask printing of 2 orders on shop with ID 4523. The screen below stalls for more than 10 minutes without ending.

This was tried with at least another shop as super-admin.

The same reports were edited correctly using chromium on the same computer (and with Firefox by another user with another computer).

Severity

bug-s3: a feature is broken but there is a workaround

[filipefurtad0]

I could not reproduce this in staging, however, it seems to be happening in production.

To the dev picking this up - it looks like this is the related Bugsnag error: https://app.bugsnag.com/open-food-france/coopcircuits/errors/65d4639bd6f75a0008d8ef8c?filters[error.status]=for_review&filters[event.since]=30d

Transcribing as errors for Coopcircuits are kept for 30 days only:

app/jobs/bulk_invoice_job.rb:27:in `sorted_orders': undefined method `map' for nil:NilClass

    order_ids.map { |id| orders_by_id[id.to_i] }
             ^^^^ (NoMethodError)
    from app/jobs/bulk_invoice_job.rb:10:in `perform'

[abdellani]

I noticed the same bug on AU-Prod https://onenr.io/0EjOnNxlpR6

The job was created with bulk_ids = null.

This is weird because if you don't select any orders, the actions dropdown will be disabled.

[abdellani]

I tried to inspect the issue on Newrelic. Between 8:53 and 8:55, there are 5 calls to bulk invoice (through "StimulusReflex::Channel#receive") and 5 records containing "Enqueued jobs" (This is printed when sidekiq load a job). 5 of 5 bulk_invoice calls have an array of IDs and they are identical. 2 of 5 jobs have bulk_ids = null

is it safe to conclude that the issue is not on the UI?

[tschumilas]

Just adding a video with console from OFN-Canada. I returned to this page after 30 minutes (my browser was still on the page) and saw the message that the invoices had been compiled - so eventually they did compile. I don't know how long that took.

https://github.com/openfoodfoundation/openfoodnetwork/assets/13171778/8b3f1ba2-89af-459f-843b-63135f3ff293

[abdellani]

I suggest waiting for this PR https://github.com/openfoodfoundation/openfoodnetwork/pull/11918 it updates the affected part.

[abdellani]

is this still happening?

@nicolasVr @RachL @filipefurtad0

[filipefurtad0]

Hey @abdellani :wave: :-)

On devops notification, this seems to be the last occurrence (2 months ago):

https://app.bugsnag.com/yaycode/openfoodnetwork-uk/errors/65e98a74dafe660008659feb?event_id=65e98a7400ddc91ce3130000&i=sk&m=nw

Maybe we can close?

[RachL]

I wonder if this isn't a stimulus reflex problem? and therefore only happening sporadically? that being said I don't know if SR is used in the loading screen.

Let's close and reopen if we get another occurence or if @nicolasVr has still users who end up in this situation.

[nicolasVr]

It is solved for me. I have emailed the customer who first reported the bug to check if it is ok for him. Thanks !

[nicolasVr]

Also solved for the customer !

[nicolasVr]

Unfortunately I just had 2 customers this week who could not print invoices. I have tested and also got the problem. I think we can re-open the issue as a new issue would have the same description.

[RachL]

@nicolasVr so the issue is again on firefox only? I'm not able to reproduce :/

[nicolasVr]

I could reproduce this morning with Firefox. I can check again later. The customer who had difficulties last week tried with Edge and Chrome. I am not sure it is browser dependent.

24 juin 2024 10:06:57 Rachel Arnould @.***>:

@nicolasVr[https://github.com/nicolasVr] so the issue is again on firefox only? I'm not able to reproduce :/

— Reply to this email directly, view it on GitHub[https://github.com/openfoodfoundation/openfoodnetwork/issues/12215#issuecomment-2185877041], or unsubscribe[https://github.com/notifications/unsubscribe-auth/ALCZK6KLSJZFXM26T3S4HILZI7H5RAVCNFSM6AAAAABD6G73TSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBVHA3TOMBUGE]. You are receiving this because you were mentioned. [Image de pistage][https://github.com/notifications/beacon/ALCZK6MQXMBB3RMNK4B7CQTZI7H5RA5CNFSM6AAAAABD6G73TSWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTUCJHLDC.gif]

[abdellani]

I checked the bugsnag report for the last 7 days and I couldn't find any issues related to the invoices bulk printing. https://app.bugsnag.com/open-food-france/coopcircuits/timeline?filters[event.since]=7d&pivot_tab=error I think this is a different problem from what @filipefurtad0 reported https://github.com/openfoodfoundation/openfoodnetwork/issues/12215#issuecomment-1969267700.

[tschumilas]

I have not been able to reproduce this, using Chrome, on OFN-Canada. Is the issue that NO bulk printing is working? I ask because it does take a while to compile - maybe the user didn't wait? I just selected and printed 100 invoices - took just over 1 minute to compile. This is the most invoices you can print becuase the selection is lost if you select a second page, and 100 is the most orders you can view per page. (When I bulk print my orders - over 100 -- I set the pagination to 100 orders per page view, and print each page's orders separately)

[nicolasVr]

I just made further tests with Firefox /Linux : as a normal user it was fast for 2 invoices and about 3 minutes for 50 invoices. As SA for 8 invoices it has been working for 4 minutes before I stop. And now another trial with 15 invoices nothing happens (no wheel). Just tried with Chromium linux with 15 invoices, it worked in about 15 seconds. During all those trials I received no email with attached reports.

[tschumilas]

Don't you just love sporatic and random bugs?

[mkllnk]

We observed this here in Australia as well. Invoices never showing up even though there were compiled. We don't have a workaround at the moment.

[dacook]

This is similar to the problem with reports. Although we haven't been able to prove the exact cause, it's likely due to a websocket message not getting through (eg due to browser timeout when busy server fails to respond to ping request after 10 seconds).

1. Similar to reports, it is a longrunning job that produces an output, but with no persistent way to access the output. With reports, we send an email with the link if it takes a long time. So if the message doesn't appear onscreen, at least you get a notification. We could consider doing the same here.
2. In the long term, we intend to replace the CableReady / WebSocket implementation anyway, so we could do that. We don't have a solution ready for longrunning jobs, I will discuss ideas in Slack.
3. Another option is to produce each invoice separately, and provide each one as it becomes available. I think we could trigger the download in the browser as each becomes available, otherwise you'd have to click on each and every one. In any case, if the websockets fail, you still get left waiting indefinitely for the results (or perhaps worse, one is missing but you don't realise).

[dacook]

Discussed with Maikel and Gaetan, I will make a start on replacing the CableReady/WebSocket implementation with HTTP polling. This will maintain the existing behaviour from a user point of view, but will be able to ensure the PDF is presented once ready.

[RachL]

@dacook FYI in the new invoice system (see feature toggle "invoices"), invoices are stored individually. Maybe it would help point 3?

Another option is to produce each invoice separately, and provide each one as it becomes available.

Currently invoices are not released as they rely on core funding, it's mostly paused. But there is not so much work left to release them. Mostly some fine tuning and s3s. https://github.com/openfoodfoundation/openfoodnetwork/milestone/69