diff --git a/ayanova/devdocs/todo.txt b/ayanova/devdocs/todo.txt index 762f1479..0f2e285e 100644 --- a/ayanova/devdocs/todo.txt +++ b/ayanova/devdocs/todo.txt @@ -17,10 +17,17 @@ Not sure what to do about that, maybe more timeouts in more places? What are the specs for the droplet? todo: figure out how jsreport is launching headless chrome, i.e. which settings and flags etc + https://github.com/puppeteer/puppeteer/blob/main/docs/api.md#puppeteerlaunchoptions + https://jsreport.net/learn/chrome-pdf + https://github.com/jsreport/jsreport-chrome-pdf/blob/master/lib/conversion.js + todo: look over this: https://github.com/puppeteer/puppeteer/issues/1834 todo: look at guidance for running puppeteer (js) on alpine docker here: https://github.com/puppeteer/puppeteer/blob/main/docs/troubleshooting.md#running-on-alpine todo: test with generated huge data locally here in Windows, see what limits get hit and how it handles it - +todo: document (or tell Joyce) about the troubleshooting section items here: + https://jsreport.net/learn/chrome-pdf + which may or may not apply in our case + todo: more timeouts for report rendering, Devops droplet is overwhelmed by 10k records of widgets using the customfields example report symptom is super high cpu usage (100%) pegged and probably virtual memory usage as well timeout is kind of a hard core way to work around this issue, maybe instead it should be looking at excessive cpu and memory usage? @@ -31,6 +38,8 @@ todo: more timeouts for report rendering, Devops droplet is overwhelmed by 10k r todo: look at metrics snapshot lifecycle, perhaps it should be shorter as it's missing 100% cpu pegging during big rendering on devops todo: pdf page numbers control + Test this, it might do what we need as it has a template for pdf footer and page number is part of it + http://www.puppeteersharp.com/api/PuppeteerSharp.PdfOptions.html look at jsreport what do they include in their pdf post processing parameters and capabilities need to add pdfkit or whatever it's called at the front.