How to resolve <refname> and #0(eval) placeholders in a Rhino stack trace?

MiaoZhan
Tera Contributor

3 hours ago

Hi all,

I'm trying to find what's setting a custom field (u_category) on sc_req_item when a Catalog Item is submitted. The value gets populated automatically, but I cannot locate the source.

What I've already checked (nothing found):

  • Business Rules on sc_req_item, sc_request, task, and sc_cat_item
  • The Catalog Item's Workflow / Flow Designer
  • Dictionary default value
  • Catalog UI Policies and Catalog Client Scripts
  • Variable default values and variable-to-field mapping
  • Data Policies
  • sys_template records targeting sc_req_item

Diagnostic probe:

I added a temporary Business Rule on sc_req_item (before insert/update, when u_category changes) to capture the call stack:

(function executeRule(current, previous) {
    gs.log('=== u_category changed ===\n' +
           'From: ' + (previous ? previous.u_category : 'INSERT') + '\n' +
           'To: '   + current.u_category + '\n' +
           'Stack: ' + new Error().stack,
           'FIELD_TRACE');
})(current, previous);

Result on submit:

=== u_category changed ===
From:
To: a7fa30f21b39ed50ef0da79ce54bcb39
Stack:
  at sys_script.fe26fe6b2bbccb106653fa9dc891bfae.script:6 (executeRule)
  at sys_script.fe26fe6b2bbccb106653fa9dc891bfae.script:9
  at #0(eval):8
  at <refname>:17
  at sys_ws_operation.4f9131449f901200d54dd4b4232e708d.operation_script:44 (process)
  at sys_ws_operation.4f9131449f901200d54dd4b4232e708d.operation_script:57

So the chain originates from a Scripted REST API (sys_ws_operation), which calls something on line 44

response_body = cart.orderNow(request_body);

, which in turn calls a script (<refname>) at line 17, which runs an eval at line 8 that ultimately writes u_category.

The Scripted REST API source is readable, but the call on line 44 appears to use a dynamic evaluation pattern (likely GlideEvaluator.evaluateString, GlideScopedEvaluator, or new Function(...) reading a script stored in a configuration record), which is why Rhino prints <refname> and #0(eval) instead of a real script name.

My questions:

  1. Is there a supported way to resolve <refname> and #0(eval) placeholders in Rhino stack traces to the actual underlying script (Script Include name, record sys_id, or scope)?
  2. Does Session Debug (System Diagnostics → Session Debug → Debug All) reliably surface the real script name for dynamically evaluated code? Or is there a more targeted setting?
  3. Can the JavaScript Debugger break inside a script that was loaded via GlideEvaluator / new Function, and if so, what's the recommended setup for code triggered by a REST request (not an interactive session)?
  4. Are there built-in APIs (e.g., GlideStackFrame, gs.getSession().getStack(), transaction tracing) that give richer frame metadata than new Error().stack?

Any pointers appreciated — I'd like to avoid string-searching every sys_script_include and sys_ws_operation record for eval( if there's a cleaner debugging approach.

Instance version: Zurich

Thanks!

0 Helpfuls
  • 89 Views
1 REPLY 1

Tanushree Maiti
Mega Patron

3 hours ago

Hi @MiaoZhan 

 

Did you check following things:

1. Have you check Audit log on u_category

Open the RITM record ->Right Click on top bar ->History ->list

Check the history of updated on u_category ( who updated with time)

 

2. Open the catalog item, look for the Process Engine section, and check the attached Flow, Subflow, or Workflow. Look for an "Update Record" action or "Set Values" logic within the first block

3. Search Business rule , Add Script column in list view and check if script contains "current.u_category"

4. Inbound Action ->  how u_category is getting set

 

Please mark this response as Helpful & Accept it as solution if it assisted you with your question.
Regards
Tanushree Maiti
ServiceNow Technical Architect
Linkedin:
0 Helpfuls