While loop stuck infinitely repeating

[Christopher Ros]

Hello everyone! So I have an API that creates Requests. I've recently been coding to account for duplicate returns. The expected behavior is a while loop that is supposed to cycle through every active employee ID it finds, creating a REQ for each, then finish. For whatever reason it's repeating the one return infinitely. 

Here's the code:

var gr = new GlideRecord('sys_user');
gr.addQuery('employee_number',requestObjFields.employee_id);
gr.addQuery('active',true);
gr.query();
while(gr.next()){
var EmployeeTermCatalogItemID = "5cd3e62bdbdb7300ceec3caf9d96196d";
var catalogItemVariables = buildCatalogItemVariables(RequestObject);
if(error.occured){
return error.content;
}
var cart = new Cart(null,catalogItemVariables.term_supe);
var item = cart.addItem(EmployeeTermCatalogItemID,1);

for(var key in catalogItemVariables){
var value = catalogItemVariables[key];
cart.setVariable(item,key,value);
}
var reqGR = cart.placeOrder();
response.setBody({
'Number':reqGR.getValue('number'),
'URL':"https://"+gs.getProperty('instance_name')+".service-now.com/sp?id=sc_request&sys_id="+reqGR.getUniqueValue()+"&table="+reqGR.getTableName()
});
}

Any help is GREATLY appreciated! Thank you!

[MrMuhammad]

@christopherroser, Please bring "Employee Number" to your sys_user table list and put the filter like Employee Number is <employee_ID_used_in_script> and see how many records it returns. If it is 669 then the issue is certainly with data and script is working as expected.  

 

Please mark this accepted/helpful, if applicable.

Thanks & Regards,

Sharjeel

[Mwatkins]

Generic troubleshooting tip for this type of thing:

• Open [your instance].service-now.com/stats.do
• Find your transaction
• Click the blue link
• This will give you the callstack of what the thread is doing by bringing up threads.do page with the specific thread filtered (e.g. /threads.do?sysparm_thread=Default-thread-1)
• In the thread stack look for lines that include configurable records (sys_metadata) like sys_script, sys_ui_action, sys_script_include and so forth. The sys_id in those lines will tell you what record is being executed and the line number will even be shown.

In regards to your specific case. Either one of two things is happening. Either you are in a true infinite loop or you are in an unexpectedly long loop.

Issue #1 Really long unexpected loop

The previous posters are suggesting that perhaps the outer GlideRecord loop is executing for many many sys_user records in your system because requestObjFields.employee_id has not been defined. This triggers a bit of platform behavior that catches many people off guard.

The problem:
When someone uses GlideRecord.addQuery(goodFieldName, undefinedCondition) we treat this as goodFieldName=NULL.

The solutions:

#1 Check for all values before using them - coding best practice
- https://developer.servicenow.com/dev.do#!/guide/orlando/now-platform/tpb-guide/scripting_technical_best_practices
To avoid unpredictable results and warning messages, verify that variables and fields have a value before using them. Consider the following code:
var table = current.cmdb_ci.installed_on.sys_class_name;
gs.print('Table is: ' + table);
Any additional statements which use the variable table may throw warning messages in the system log if the value is undefined. This can happen if the cmdb_ci field is empty or if the installed_on field in the CI is empty. The following code demonstrates a better way to verify that the table variable has a value before using it:
var table = current.cmdb_ci.installed_on.sys_class_name;
if (table) gs.print('Table is: ' + table);
else gs.print('Warning: table is undefined');

#2 Change the behavior
- glide.invalid_query.returns_no_rows
- GlideRecord queries with addQuery with undefined "parameter" will cause the query to treat it as a null condition, potentially bringing back a very large result set. The property "glide.invalid_query.returns_no_rows" changes the behavior of the case of addQuery(goodFieldName, undefinedCondition) to basically return no results in very efficient fashion by adding 1=0 to the conditions.

#3 Use the new GlideQuery API
- There is a new feature that is currently being used (primarily internally) that helps developers write better/safer ServiceNow Glide code.
- GlideQuery effectively sits on top of GlideRecord and provides additional error checking/improved syntax. As a result, for well written queries, i wouldn’t expect to see any difference in debug SQL output between the two (as the same GlideRecord() queries should be run in both cases) - the product team has documented some single digit performance overhead that I assume is due to the additional logic added by GlideQuery before it calls GlideRecord
- It was discussed during K20 recently by the ServiceNow developer Peter Bell whose team is developing it.
- At this point it is a very new and perhaps less rigorously proven API. Caution is recommended.
https://events.servicenow.com/widget/servicenow/knowledge2020/myagenda/session/1581555110988001mNP1?sessionId=1581555110988001mNP1
- Jace Benson (not a ServiceNow employee) explained how it can be installed and used already.
https://jace.pro/post/2020-05-29-how-to-install-glidequery/

Issue #2 Infinite Loop

In this case there is truly a never ending loop. How could this happen based on your code? There are two loops in your code. A while loop that uses gr.next() and for loop that iterates over properties in an object. Neither should produce an infinite loop logically under normal conditions. But perhaps something abnormal is happening. Here are some ideas of weird situations that you might be hitting:

• The variable "gr" is a very common variable name. Perhaps some downstream code is altering the value of "gr" such that we never get to the last "gr".
• Perhaps "gr.next()" is a field on your sys_user table. In that case, there is a weird edge case that would be fixed by calling gr._next().
• Perhaps the infinite loop is not anywhere in the code you posted. The code you posted calls Cart.addItem, Cart.setVariable, Cart.placeOrder, buildCatalogItemVariables and so forth. Maybe one of these is in an infinite loop. Checking stats.do and threads.do should clear this up.

[Christopher Ros]

Wow thanks for the extensive type up! I'm still relatively new to coding so this type of information is extremely useful. Thank you!

[DirkRedeker]

Hi

I guess, if you are sure, that the WHILE loop is endless, there must be some "gr" manipulation in "buildCatalogItemVariables()" as well. 

Check that function, if it uses a "gr" variable, and let me know about the content of that function.

BR

Dirk

[Michael Ritchie]

Great point and exactly why it is never good practice to use "gr" as a variable.  I have lost many hours to this exact situation and now always name my variables to what they are.  It makes it much easier to read for someone else coming along reading the script.