feat(print): table of content

[usu]

Based on #2554

Adds implementation for table of content

If no-one has started review for #2554 we can directly review this one and close #2554.

[carlobeltrame]

I did a first pass of reviewing. Will need to do a second one, and test it locally.

It doesn't seem to work yet on https://pr2562.ecamp3.ch/
The print container does not start, it shows the error:

ERROR Unexpected token u in JSON at position 0
at JSON.parse (<anonymous>)
at server.js:926:23
at promisify (.nuxt/utils.js:311:0)
at middlewareSeries (.nuxt/utils.js:291:0)
at module.exports.__webpack_exports__.default (.nuxt/server.js:158:0)

This can happen when some config value is undefined (could be an environment variable)

[carlobeltrame]

The deployment works now, thanks! But in the default configuration I get only one page in the preview, even though it is numbered with "Page 1 of 10" at the bottom. Any ideas why this happens?

[usu]

The deployment works now, thanks! But in the default configuration I get only one page in the preview, even though it is numbered with "Page 1 of 10" at the bottom. Any ideas why this happens?

Fixed with 9543a93

PostCSS shortens CSS selectors from double colon :: to single colon :
PagedJS doesn't like this

As PostCSS only runs in build mode but not in development mode I didn't recognize during local testing.

[carlobeltrame]

Merci für die Fixes! Habs gerade nochmals auf dem Deployment getestet, und es verhält sich momentan sehr seltsam. Was ich gemacht habe:

1. Eingeloggt mit test-user, Sprache automatisch Englisch, Browser Firefox, in Lager GRGR auf Print Tab
2. Nuxt Preview hat normal gerendert
3. (Ich habe noch etwas mit der Mobile View gespielt, um auszutesten ob die Preview jetzt immer unter der Config ist)
4. React Preview Tab angeklickt
5. React Preview hat normal gerendert
6. Picasso aus der Config entfernt
7. React Preview hat normal gerendert
8. Zurück auf Nuxt Tab
9. Preview blieb weiss, Request an print-pr2562.ecamp3.ch wurde nicht abgeschlossen (und wenn er nicht gestorben ist lädt er noch heute)
10. TOC an die zweitoberste Position verschoben, um zu sehen ob ein weiterer Request hilft. Der weitere Request kam mit HTTP 524 zurück (der erste ist immer noch pending)

Auf Kubernetes Dashboard war der Print-Container kurzzeitig nicht mehr healthy, im Log steht wiederholt folgendes:

 ERROR ServerException: Error trying to fetch "/activities/2a99033ce9c3" (status 520): Request failed with status code 520
at A (/app/node_modules/hal-json-vuex/dist/bundle.js:1:11027)
at /app/node_modules/hal-json-vuex/dist/bundle.js:1:9070
at processTicksAndRejections (node:internal/process/task_queues:96:5)
at async Promise.all (index 1)
at async a.fetch (components/toc-program.js:47:5)
at async a.serverPrefetch (server.js:1941:5)
at async Promise.all (index 0)

(bzw. zuerst stand noch dasselbe mit /content-types/1a2b3c4d)

Caddy und PHP wollen gemäss Logs von einem Status 520 nichts wissen, waren aber auch kurzzeitig nicht healthy (Indikator ist inzwischen wieder grün, aber in den Events ists protokolliert)

Entsprechend entstandene Sentry-Issues sind:
https://sentry.io/organizations/ecamp/issues/3158505352/
https://sentry.io/organizations/ecamp/issues/3158504107/
https://sentry.io/organizations/ecamp/issues/3158504241/

Der Print Container ist nach dem beschriebenen Reproduktions-Ablauf permanent zerschossen, und kriegt sich erst wieder ein wenn ich manuell den Print-Pod lösche und vom Deployment automatisch wieder ein neuer hochgezogen wird. Mit "zerschossen" meine ich, manchmal kann man nicht mal mehr die Logs des Containers anschauen:

Get "https://10.114.0.7:10250/containerLogs/default/ecamp3-pr2562-print-74b57db55c-747hf/ecamp3-print?tailLines=5000&timestamps=true": net/http: TLS handshake timeout

Ich konnte das gerade nur 2 von 4 Mal reproduzieren. Danach waren auch noch kurzzeitig die meisten anderen Pods in unserem Cluster down. Ist schwer zu sagen ob das wirklich ich ausgelöst habe oder ob DO gerade etwas an der Infrastruktur gemacht hat. Aber bei den zwei fehlerhaften Versuchen hats immer zuerst geklappt, und erst beim Zurückkommen vom React Tab dann nicht mehr.

[carlobeltrame]

Noch etwas: Wenn ich auf der standard Print Config die "print day overview" Checkbox spamme, kommt vom Print Service ein 500er zurück. In den Logs sagt er dann, von der API komme ein 503 (Service Unavailable), in den Caddy Logs steht 502 (Bad Gateway) und im PHP Container folgendes:

[04-Apr-2022 15:56:25] WARNING: [pool www] server reached pm.max_children setting (5), consider raising it
[...]
[04-Apr-2022 15:56:31] ALERT: oops, unknown child (157) exited with code 0. Please open a bug report (https://bugs.php.net).

Wenn ich das richtig verstehe crasht dabei der PHP-Prozess, und wird dann im gleichen Pod wieder gestartet (hat nachher weiterhin PID 1, aber die vormaligen Logs verschwinden).

Das max_children tritt auch immer wieder mal auf wenn ich nicht gerade am printen bin, sondern nur viele Requests gleichzeitig zur API kommen. Aber das unknown child exited ist mir bisher nur beim spammen der Checkbox im Nuxt-Modus passiert.

[usu]

Wenn ich das richtig verstehe crasht dabei der PHP-Prozess

Ich würde behaupten, du hast gerade die erste DoS-Attache auf ecamp gefahren 🤣
Sollte mit #2571 deutlich besser sein. Wenn wir die Preview später auch noch haben wollen, braucht es wahrscheinlich ein Throttle. Mache im Epic eine Notiz dazu.

[usu]

Caddy und PHP wollen gemäss Logs von einem Status 520 nichts wissen, waren aber auch kurzzeitig nicht healthy

520 ist von cloudflare (https://support.cloudflare.com/hc/en-us/articles/115003011431-Troubleshooting-Cloudflare-5XX-errors#520error) und heisst wahrscheinlich, dass PHP/Caddy tot ist. PHP abschiessen konnte ich reproduzieren, Print-Server bisher noch nicht.