ayanova/devdocs/todo.txt

@@ -14,46 +14,34 @@
 
 
 
-
-
-
-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: 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
 	
 
+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
 	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
 			must be end to end so that all aspects are tested as much as possible
 			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
 	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: should some things that were tagified be reverted back like in v7 due to reporting and other issues?