Hey Liam,
Thanks for your engagement, situations like this are exactly what I hope the new logging can help with, you could just put a unique log in each condition to find out which condition had the problem.
I would be looking for some variable that could equate to None on line 2, maybe try switch the conditions into python 2 one at a time until either the error goes away or switches to a different format that does not reference cpython (python3), then you'll know which one has the problem.
It would be good for us to maybe add the display name of the script in the error message, but the problem is conditions don't have names so i'm not sure what we could add there. I'll have a think about it and see if we can come up with an enhancement to help.
------------------------------
Sean Mc Cann
------------------------------
Original Message:
Sent: Wed August 25, 2021 10:42 AM
From: Liam Mahoney
Subject: Improved Script logging in SOAR v42
Sean,
I appreciate the work you and the team are doing to make the developer experience better. This should be a good change and I'm excited to be able to use it.
I've been battling with an error in a condition script for 45+ minutes so I thought I'd share to see if you guys could improve the logs in this situation (or maybe point out that I'm missing something).
I'm getting this error in the action status:
An error occurred while processing the action acknowledgement. Additional information: Script condition from Workflow '[SOC] Suspicious Email Automation' running on Incident 'SN: EML0115619' was unable to complete because: AttributeError: 'NoneType' object has no attribute 'get'
and in /var/log/resilient-scripting/resilient-scripting.log
I'm seeing the following:
09:30:54.628 [qtp1611188160-83595] WARN v=unknown c.r.s.rest.ExceptionMapperBase - Error executing script, 'AttributeError: 'NoneType' object has no attribute 'get'' on line number 2com.resilient.scripting.exception.UserScriptingException: null at com.resilient.scripting.cpython.process.CPythonProcessCommsHandler.handleFrame(CPythonProcessCommsHandler.java:114) at com.resilient.scripting.cpython.process.CPythonProcessCommsHandler.lambda$handleMessagesFromProcess$0(CPythonProcessCommsHandler.java:143) at com.resilient.scripting.cpython.process.CPythonProcessCommsHandler$$Lambda$83/00000000A81832D0.run(Unknown Source) at java.lang.Thread.run(Thread.java:822)
So I know it's a condition that has a script in it, and I can use which functions executed in the action status to gauge roughly where in the workflow this condition should be, but I'm struggling to find the condition where this error is happening. It'd be really nice if there was a way to identify exactly which condition this error was happening in from the log message.
------------------------------
Liam Mahoney
Original Message:
Sent: Thu August 19, 2021 09:33 AM
From: Sean Mc Cann
Subject: Improved Script logging in SOAR v42
Hi all,
Just wanted to share with you some improvements we have made to logging in Python 3 scripting in the latest version of SOAR. This will hopefully help anyone writing scripts, workflows, playbooks or functions. These changes do not apply to Python 2.
When writing scripts, you have access to log statements as described here: https://www.ibm.com/docs/en/rsoa-and-rp/42?topic=scripts-log-operations
In previous versions, these log statements were only shown when interactively running a script. In v42 these log messages will also be written to the resilient-scripting.log file to help with debugging Python 3 scripts. The advantage of this is that you can view logs even when the script is run by an automated rule or playbook, and also view the logs of failed scripts.
Here is an example of a simple log statement
Scripts that throw an error will also display logs leading up to the error
And perhaps the most useful part of all, is that scripts in a workflow function can also be logged, meaning the results of a function can be debugged without having to add notes to an incident or any other workaround. You can also log out any of the built in object types such as incident
or task
to view the object data.
We hope this helps to address some of this RFE https://2e4ccba981d63ef83a875dad7396c9a0.ideas.aha.io/ideas/R-I-400 and improve the script developer experience. Again this is only available in Python 3 scripts in v42. The log output will always be filtered by the logging level of the scripting server so by default debug level statements will be excluded.
Thanks,
------------------------------
Sean Mc Cann
------------------------------