ayanova/devdocs/todo.txt

@@ -241,18 +241,63 @@ TODO: 1 BETA DOCS:
 ██████  █████   ██████  ██    ██ ██████     ██    ██ ██ ██  ██ ██   ███ 
 ██   ██ ██      ██      ██    ██ ██   ██    ██    ██ ██  ██ ██ ██    ██ 
 ██   ██ ███████ ██       ██████  ██   ██    ██    ██ ██   ████  ██████  
-                                                                        
 
 
 
+- 1 todo: error handling improvement:  DO THIS NEXT 
+	if the chromium process is killed while rendering by the sweeper, the browser gets back a temporary error message that it pops up:
+	{"error":{"code":"2030","message":"Protocol error(Page.printToPDF): Target closed. (The remote party closed the WebSocket connection without completing the close handshake.)"}}
+	This is not good as it vanishes by and is basically meaningless to users
+	So, server should not return this error but instead return a timeout error if it sees this was the error
+	To test this out use the large data set and run 1800 wo dispatch report with the timeout set to 6 minutes which is enough time for the browser to kick in but not enopugh to complete the job
+		may need to re-run a few times as the timing is wonky when the sweeper job kicks in
+
+	TODO: throw the same exception when this error is detected as if timed out normally in reportbiz which in turn should trigger proper error handling at both ends (log in server, clear message in webapp)
 
 - 1 todo: add the caching technique to *all* the other getreportdata methods as was done with workorder 
-- 1 todo: chromium seems to be launched 6 times for one report, when the report is done and sent 3 instances close but three remain with one being super busy and eating up ram still
+
+
+
+- xx DONE?: kill chromium better NOT TESTED YET ON LINUX
+	
+	ok, seeing that the process id that we get from teh browser does not include the process actually doing the work, if it needs to kill it, it seems to kill some other chromium process that isn't the one in question
+
+	if chromium process issue arises again, could add code to look for chromium process that are not in the bag but are started from our private instance folder and shut those down 
+	during sweeper cleanup job
+
+	foreach (Process PPath in Process.GetProcessesByName("notepad"))
+	{
+		string fullpath = PPath.MainModule.FileName;
+		Console.WriteLine(fullpath);
+	}
+
+	IDEAS:
+		
+		-1 - Process.Kill has a bool to kill child processes which I was not setting, fuck, this might fix it all completely..testing...
+			YES YES YES, worked in windows in one test.
+
+		0- does .net give age of process, if so then easy peasy because can step through all chromium processes that are in our path and kill any over the expiry time
+			YES!!
+			https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.process.starttime?view=net-6.0#System_Diagnostics_Process_StartTime
+			https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.process?view=net-6.0#properties
+
+		1- check if no unexpired print jobs active in bag and if so then kill any chromium processes found (takes care of hangers on but only works when there is a lull in printing)
+		2- step through report render, look for processes being created, see if there is a moment when they can be read back from windows and added to bag
+			i.e. what processes did it *just* start and toss them in the bag with same expiry date then proceed
+		
+
+- xx DONE SEEMS OK: Is there a reason to open a new page or can I re-use the initial browser page because it seems like the extra page is causing extra hassles as it's process is different from the browser pid
+	did it, seems ok, no issues noted
+
+
+- 3 COULD NOT REPRODUCE / DOWNGRADED TO BOLO todo: chromium seems to be launched 6 times for one report, when the report is done and sent 3 instances close but three remain with one being super busy and eating up ram still
 	wtf are there so many processes?
 	2gb of ram in the zombie unasked for chromium process wtf?
 	Is it doubling the work somehow, seems like the second chromium is re-doing the work of the first or at least it's busy for no real reason?
 	Does a Page have it's own process id like it's a whole browser running?
 	Go headful and watch what is happening, figure it out
+	COULD NOT REPRODUCE, did make some changes and it could have been leftovers from earlier shit maybe
+	 	will downgrade and keep an eye on this
 
 
 
@@ -795,6 +840,8 @@ BUILD 8.0.0-beta.0.6 CHANGES OF NOTE
 	It's potentially possible that it's age is out by an hour if there is a DST change between now and when the wo was created
 	Note that this AGE value is not used for anything other than displaying to the user so it's not going to break anything if it is out by an hour in some cases.	
 - Added caching to workorder report viz field resulting in a 160% report rendering speed improvement in a test of 100 workorders
+- Added caching to pm, quote report viz fields
+
 - fixed "Service Dispatch" report template that had a duplicate translation key in it: "WorkOrderItemPartQuantity"
 	(note you can check for this during report development by looking at the server log which will show the following error when the report is rendered:
 	2021-12-22 16:19:07.0290|ERROR|AyaNova.Biz.TranslationBiz|********* GetSubsetAsync problem: Duplicate keys: WorkOrderItemPartQuantity)