Non-sensical kb_knowledge_base Error During Record Iteration

[Justin Griffin]

We are getting the error:
org.mozilla.javascript.EcmaError: Cannot read property "kb_knowledge_base" from null
Caused by error in sys_script_include.efed9e521b7eb700b05ddce8dc4bcb1c.script at line 27

This is only happening on one instance that was just zbooted and is running the Utah pre-release. Taking a look at the code in question, this is what's there: 

        var lang = [];
        var gr = new GlideRecord('kb_knowledge');
        gr.addQuery('sys_id', 'IN', ids.toString());
        gr.query();
		gs.debug('Rowcount = ' + gr.getRowCount());
        while (gr.next()) {
            if (lang.indexOf(gr.language.toString()) == -1)
                lang.push(gr.language.toString());
        }
        if (lang.length > 1) {
            answerArray['languageCheck'] = false;
        } else {
            answerArray['languageCheck'] = lang.toString();
        }

Rowcount is 1 in the logs, so we know that the while gr.next() should run one time. Instead, it fails on some non-sensical error saying that kb_knowledge_base cannot be read from null. First, we know from logs that gr is not null. Second, nowhere are we referring to kb_knowledge_base. Anybody have ANY idea what's going on here? Eliminating the while loop eliminates the error, but then the code doesn't do what we want.

[Justin Griffin]

Sorry, I forgot to add that the line 27 itself is this:

while (gr.next()) {

[Warren Shekyls · Accepted solution]

Not sure if you ever solved this, but we came up against this with one of our Scoped Apps, our code worked fine in Global. We resolved this by adding a Cross Scope Privilege to the kb_knowledge_base table for read access.

Seemed to solve our issue, what is strange is that on other instances we were not seeing this issue, even though the instances were on the same family.

[Justin Griffin]

Hahaha, Warren that's exactly how we solved it as well. I'll mark your answer as the accepted solution. Interestingly enough we had the same thing where it worked on our other instances without that cross scope access. No idea what's going on here but at least there's an answer.