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 ?
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.
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."
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.
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.
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.
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.