admin/raven-client
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Browse Source
This commit is contained in:
John Cardinal
2021-10-28 18:27:55 +00:00
parent 27910abad9
commit 3d01fea58d
1 changed files with 13 additions and 33 deletions
Download Patch File Download Diff File Expand all files Collapse all files

46
ayanova/devdocs/todo.txt
View File

@@ -14,46 +14,34 @@
todo: timeout for reporting should be used for all areas where a timeout is specified for puppeteer sharp so that everything is in agreement
or, maybe what is required is to set them unusually high to allow for mega reports adn let the zombie reaper handle based on user settings!!!
because we don't want a 30 second limit in puppeteer to kill a report when they set it to be 2 minutes timeout because they know they have a huge report to print from time to time
ISSUE: reporting failing on linux under load
well, not failing exactly, but eating up all resources and bringing to a halt
possible reporting issues solution: don't start a new report until last one finished
i.e. it should wait until the last report has resolved before spinning up a new one
this would resolve the linux issue I think where it gets overloaded because it's trying to do too many at once
maybe a setting for a hard limit on number of reports currently running or instances of chrome started by report
zombie processes?
https://developers.google.com/web/tools/puppeteer/troubleshooting#running_puppeteer_in_docker
READ THIS TOO IT'S RELEVANT:
https://github.com/dotnet/runtime/issues/21661
https://stackoverflow.com/questions/43122080/how-to-use-init-parameter-in-docker-run#44689700
todo: rejig render stuck process killer to be thread safe and have a configurable number of allowed running simultaneous headless browser pdf processors
ideally it should allow at least two or three instances at once and track all and return a server busy response to try again if no free slot available
so it will need a list of instances with age and process id
Report rendering at client must respond back with the too busy message and try again
503 Service Unavailable
todo: add code for client reporting to handle a busy response
perhaps it retries after the delay a fixed number of times then reports back a fail / retry later to the user
joyce suggested a folksy message regarding server busy, something friendly and non techy sounding
I'm thinking people would not see this message very often hopefully
AUTOMATED TESTING AUTOMATED TESTING
NEEDS: NEEDS:
Acceptance "smoke" testing to ensure can release confidently "E2E" testing CYPRESS: Acceptance "smoke" testing to ensure can release confidently "E2E" testing
After code changes need compliance test that everything is still working After code changes need compliance test that everything is still working
must be end to end so that all aspects are tested as much as possible must be end to end so that all aspects are tested as much as possible
must be runnable here or against devops must be runnable here or against devops
Cypress will test e2e, can jmeter as well?? Cypress will test e2e
todo: discuss with Joyce reporting requirements and if we are at the stage to be making any real world reports yet
- stripped down bare reports with as little extra elements on page as humanly possible (as per dashboard UI advice guy)
- let the user add any elements if they want them, we want as white a page as possible in our stock reports, clean, simple, no extra bits anywhere
todo: take a sample report and strip it to see where and what can be changed to speed up generation
there are lots of indications online when using puppeteer to gen docs that too many elements slow it down and some particular ones are killer for this
@@ -63,12 +51,6 @@ investigate: hard cap on appointments brought back controlled by client in setti
applies to month view applies to month view
force user to filter by tags if too much, i.e. truncated result with error so they can see it was limited force user to filter by tags if too much, i.e. truncated result with error so they can see it was limited
investigate: hard cap timeout on anything very time consuming like report generation, datalist queries, schedule etc
if a report ties up the server for more than XX seconds it should stop it adn return an error too big
can't have server churning when user abandons op
cancellable report job?
simultaneous users reporting??
need stress / load testing setup to really get into this properly
@@ -81,8 +63,6 @@ todo: two emails with change to reports to add and also cases regarding naming i
todo: ops document where is the query timeout setting and how to adjust it for timeouts in long running queries? todo: ops document where is the query timeout setting and how to adjust it for timeouts in long running queries?
todo: should some things that were tagified be reverted back like in v7 due to reporting and other issues? todo: should some things that were tagified be reverted back like in v7 due to reporting and other issues?