[IGN-5604] scoping weirdness after call to system.report functions

Ignition
1

Hello folks,

Noticed something quite strange today.
I have a script that calls system.db.runNamedQuery a few times, and one of them would error out with this error:

java.lang.IllegalArgumentException: Project name required for script execution: the Gateway Scripting Project is not set.

Using the gateway scope version, with the project name, fixed it. But I couldn't wrap my head around this, as other calls worked just fine.
So I talked about it with coworkers, and turns one of them had the exact same issue just yesterday.
The one thing in common that's just too big to be a coincidence is that we both had a call to a report function right before the named query - executeReport for him, executeAndDistribute for me.

So I tried moving the named query to before the report function call and, lo and behold, it works just fine with the project scope syntax.

Version is 8.1.17 (at least for me, don't know about my coworkers'. I should ask).
Is this something you heard before ? Maybe it's been fixed since ? I couldn't find anything with a quick search on the forums.
Is it bug report o'clock ?

2

What do you have set here? Under config->Gateway settings.

image
image842×109 3.54 KB

And can you post the script, the before and after where you moved the lines?

3

I don't think that's relevant here: I understand what the gateway scripting project is what it's used for, but the point here is that it's not needed for the calls to runNamedQuery that happen before the call to executeReport, but it's needed after them.
Maybe setting the scripting project would fix it, but there's still something funky going on.

The script looks like this:

system.db.runNamedQuery("query_path")
function_that_runs_report_function()
system.db.runNamedQuery("other_query_path")

First query works fine, second does not, unless I use the gateway scope syntax.
If I do this instead:

system.db.runNamedQuery("query_path")
system.db.runNamedQuery("other_query_path")
function_that_runs_report_function()

the problem goes away.

That script is in a message handler, the reporting function is in the project library.

I'll talk with the coworker in the afternoon, gather some data, then maybe file a bug report.

4

What's going on in here - function_that_runs_report_function() just getting params for executeReport/executeAndDistribute?

Please update this post when you get some answer from IA, I have run into some similar weirdness where I unexpectedly need a project name for a NQ.

5

Sounds like it to me. Reporting blowing up the project thread local.

1 Like
6

I tried recreating it in 8.1.26 but it works correctly so perhaps this is a bug they were aware of and fixed? My message handling script.

def handleMessage(payload):
	logger = system.util.getLogger("TEST NQ")
	logger.info("Running NQ")
	ds = system.db.runNamedQuery("test",{"idx":1})
	logger.info("Got result %s"%(str(ds.getValueAt(0,0))))
	test.makeReport()
	logger.info("Running NQ 2")
	ds = system.db.runNamedQuery("test2",{"idx":1})
	logger.info("Got result 2 %s"%(str(ds.getValueAt(0,0))))

and my makeReport function is doing similar to yours I assume

def makeReport():
	logger = system.util.getLogger("R Logger")
	logger.info("Making report")
	data = system.report.executeReport("test_Report")
	logger.info("Made report")

This works without throwing me any error and I get what I expect.

7

If it still happens after upgrading to latest, yes.

8

I just talked to my coworker, and his project is on 8.1.30, so there's something else.
AND his scripting project was configured.

One thing though: I first tried reproducing the issue with a simple named query that was just a select 1, and no issue was raised.

Both my coworker and I are using an update named query when the issue happens. Maybe that's also a factor.

edit: Nope, tried replacing with a select 1 named query and got the same error.
Even after setting the scripting project, it says "the Gateway Scripting Project is not set."

9

I'm pretty sure this is a bug... think I found it. I'll write up a ticket.

4 Likes
10

In the meantime, can I reliably use this ?

system.db.runNamedQuery(
	path="query_path",
	parameters=params,
	project="project_name"
)

It works in both scopes, but I'm wondering if it's a reliable workaround.

11

Yes, the report scripting call is clearing out some thread local state about what the default project is, which makes the subsequent runNamedQuery without it specified fail.

1 Like
12

Is there a range of affected versions? Or has this been there forever?

13

FWIW I was wholly unable to recreate the issue in 8.1.26, I changed my SELECT to UPDATES as @pascal.fragnoud mentioned, used a combination of both, in different orders. Maybe I am doing something different in my report script, since I am only doing executeReport instead of exceuteAndDistribute. But I have had no luck recreating it in this version.

1 Like
14

Possibly since 8.0.11, but that's just the call that clears the thread local state, without investigating all the other pieces to see if it was actually affected starting that version.

1 Like
15

I'm pretty sure this has basically always been a thing; there's other manifestations of it reported 2 years ago.

One of the "under the hood" changes I'm planning to make in 8.3.0, when I have a window to break APIs, is a better/less fragile method to "stack" contexts - i.e. a report's execution setup/teardown just should not be able to "leak" to the tag event script, async thread, whatever that called it.

3 Likes