An unknown N1QL error occured. This is usually related to an out-of-memory condition

[itssrinadh]

Hi,

I implemented a simple node js API and which is working fine on local but when i deploy into the AWS server, this failing with the following error.

Error: An unknown N1QL error occured. This is usually related to an out-of-memory condition.

I kept console log also, please see the attached image.

[brett19]

Hey @itssrinadh,
It looks like there is an error with your N1QL node in AWS. Would you be able to try and do the query directly from the Admin UI and/or via the cbq command line tool?
Cheers, Brett

[itssrinadh]

Hey @brett19

It is working fine on workbench here you can see attachment.

[brett19]

Hey @ittsrinadh,
Would you be able to try using cbq from your application server? It seems likely that there is a network issue between your application server and the Couchbase Server. You may also be able to use sdk-doctor to verify the connectivity (see: https://github.com/couchbaselabs/sdk-doctor/releases https://github.com/couchbaselabs/sdk-doctor/blob/master/README.md).
Cheers, Brett

[itssrinadh]

@brett19

https://github.com/couchbaselabs/sdk-doctor/blob/master/README.md

Hey @brett19
Please find the following image, seems everything good. can you assist me, where i did wrong?

When we perform on CBQ, it is working fine. Please find the following image.

[corey_perkins]

I have the same error working on a cb instance on localhost. Version 2.5.1 and 2.6.0 of the sdk. CB version 5.5.1.

See attachment. My query works fine in the web ui.

Corey

[itssrinadh]

Hey @brett19, We are waiting for your response. Can you help us?

[corey_perkins]

Any help would be great!!! We are considering moving our project back to 4.6 because of this. 5.5 just doesn’t seem as rock-solid and reliable as 4.6 was.

[eben]

Quick question: when calling from the SDK, are you using prepared queries with positional or named parameters?

[itssrinadh]

Hey @eben It is Named parameters

Here is the code snippet.

try{
    const { companyID, upc, type } = inputData;
    // ba means bucket alias name
    const q = `SELECT ba.*, meta(ba).id from \`${bucket}\` ba WHERE companyID='${companyID}' AND type ='${type}' AND upc ='${upc}'`;
    //meta(ba).cas
    query(q, function(err, rows) {
      if (err) {
        return cb(err.toString(), null);
      }

      cb(null, rows);
    });

  }catch(e){
    cb(e.toString(), null);
  }

[eben]

Hi @itssrinadh, I checked with the query team, and they said:

1. that the “unknown error” is because the SDK is not parsing the particular error message from the query engine,

2. the errors that return that status are related to “bad values”, i.e., “named or positional values and they are repeated or invalid or…”

Is it possible that there are corrupt or invalid values in your “inputData”?

[itssrinadh]

Actually, I guess No, But I just wonder, why it is working in a local machine and when it is deployed to AWS production. we are facing this issues.

[Marco_Greco]

Hi @itssrinadh, I can’t add much more without a meaningful error message from node.js, but status 400 is generated by either a parse error or invalid parameter.
I wonder if one of the named parameters is conflicting with something that AWS uses and and by the time the request gets to n1ql it is filtered in a way that n1ql cannot make sense of.
Is there anyway you can snoop the request going out and the response coming?

[ingenthr]

If you turn the log level up, there should be some more info, including the request and response bodies. Can you have a look at that and if you need help with interpretation, post a gist or the like?

[itssrinadh]

Hi @Marco_Greco, Please find the below code snippets and console responses for Local Dev and AWS.

Snippet Code for Named Parameters:
readCostAlertDoc: async (inputData, cb) => {
try{
console.log(“InputData >>”, inputData);
const { companyID, upc, type } = inputData;
// const q = SELECT ba.*,meta(ba).id from \${bucket}` ba WHERE companyID=‘${companyID}’ AND type=‘${type}’ AND upc=‘${upc}’`;
const q = ‘SELECT ba.*, meta(ba).id from costalerts ba WHERE companyID=$companyID AND type=$type AND upc=$upc’;
console.log(“Plain Query String >>”, q);
let cluster = new couchbase.Cluster(‘couchbase://ipaddress:8091/’);
cluster.authenticate(‘user’, ‘password’);
let bucketCluster = cluster.openBucket(‘costalerts’);
let query = couchbase.N1qlQuery.fromString(q);
console.log(“N1qlQuery String >>”, query);
bucketCluster.query(query, inputData, function(err, rows) {
if(err){
console.log(“Query Error >>”, err.toString());
return cb(err.toString(), null);
}
console.log(“Query Success >>”, rows);
cb(null, rows);
});
}catch(e){
cb(e.toString(), null);
}
}

AWS Console:

Local Dev Console:

Snippet Code for Positional Parameters:
readCostAlertDoc: async (inputData, cb) => {
try{
console.log(“InputData >>”, inputData);
const { companyID, upc, type } = inputData;
// const q = SELECT ba.*,meta(ba).id from \${bucket}` ba WHERE companyID=‘${companyID}’ AND type=‘${type}’ AND upc=‘${upc}’`;
const q = ‘SELECT ba.*, meta(ba).id from costalerts ba WHERE companyID=$1 AND type=$2 AND upc=$3’;
console.log(“Plain Query String >>”, q);
let cluster = new couchbase.Cluster(‘couchbase://ipaddress:8091/’);
cluster.authenticate(‘user’, ‘password’);
let bucketCluster = cluster.openBucket(‘costalerts’);
let query = couchbase.N1qlQuery.fromString(q);
console.log(“N1qlQuery String >>”, query);
bucketCluster.query(query, [companyID, type, upc], function(err, rows) {
if(err){
console.log(“Query Error >>”, err.toString());
return cb(err.toString(), null);
}
console.log(“Query Success >>”, rows);
cb(null, rows);
});
}catch(e){
cb(e.toString(), null);
}
}

AWS Console:

Local Dev Console:

We are getting success from the Local Dev machine but same code not working in the AWS Server. Please let us know if there any additional information require to closure ?

[ingenthr]

If it’s possible to run a simple test, just a single query, in the environment with LCB_LOGLEVEL=5 set as an environment variable, it should give the ‘snoop’ that @Marco_Greco is mentioning. We’ll be able to see the request and response, and it may make it a lot more clear what’s going on. If you need help interpreting the output, please post to a gist or the like.

[ingenthr]

Also, one guess about what might be different between the two environments, something that does jump to mind is verify the roles and permissions are the same between the two environments. It could be that the user is lacking a permission in the AWS environment. I’d still expect the error to propagate differently, but it’s worth verification.

[itssrinadh]

Hi @ingenthr, Please find the below attachments for LOGs.

[ingenthr]

That’s a lotta pixels, but helpful! I’ll need to dig a bit deeper and/or check with someone else, but what the log is telling me is it goes to connect to the query service, it does connect to what it thinks is the query service, but an error is immediately received. Specifically, here:

I’ll get more info on that.

It did make me look back at your sdk-doctor output. It appears you ran that on localhost, but your error is coming from a client using 54.145.77.247 as the server. Did you run sdk-doctor from the place you run your node.js app to the server? Is it possible that there is something blocking or somehow proxying port 8093 where the query service is accessed?

[brett19]

Hey @itssrinadh,

I’ve managed to identify the problem here. It looks like the latest Node.js release (v11+) has incorrectly included special characters in some of the version numbers it exposes. In order to aid in debugging, many of these versions are included in the client identifier we pass to the server. In this case, the openssl version reported by Node.js is 1.1.0i \n as opposed to the expected 1.1.0i. Later down the line when generating the HTTP request to send to N1QL, this newline character causes confusion (since HTTP requests are newline delimited) and the request is marked as bad by the server.

I’ve opened an issue to track this issue here: Loading... .
I’ve also prepared a fix on the Node.js side here: http://review.couchbase.org/#/c/101358/ .
Additionally I’ve opened an issue for the underlying libcouchbase SDK to ensure that these kinds of errors are detected by the low-level SDK in the future here: Loading... .

I should be merging the fix sometime later this evening and you should be able to fetch it directly from Git at that point. I will also ensure that the fix gets placed in the next release, which should be available early next week!

Sorry for the inconvenience, Brett