List of Cassandra error codes - node.js

While using the datastax node.js driver I'm getting an exception code as documented under http://docs.datastax.com/en/developer/nodejs-driver-dse/1.4/api/module.errors/class.ResponseError/.
However I cannot find any documentation about all available exception codes. Anybody an idea where to find?

I'm not sure that the code values are specifically documented anywhere but you could always look at the ExceptionCode source for the version of Cassandra you are working with.
On trunk this lists the errors as:
SERVER_ERROR (0x0000),
PROTOCOL_ERROR (0x000A),
BAD_CREDENTIALS (0x0100),
// 1xx: problem during request execution
UNAVAILABLE (0x1000),
OVERLOADED (0x1001),
IS_BOOTSTRAPPING (0x1002),
TRUNCATE_ERROR (0x1003),
WRITE_TIMEOUT (0x1100),
READ_TIMEOUT (0x1200),
READ_FAILURE (0x1300),
FUNCTION_FAILURE (0x1400),
WRITE_FAILURE (0x1500),
CDC_WRITE_FAILURE (0x1600),
// 2xx: problem validating the request
SYNTAX_ERROR (0x2000),
UNAUTHORIZED (0x2100),
INVALID (0x2200),
CONFIG_ERROR (0x2300),
ALREADY_EXISTS (0x2400),
UNPREPARED (0x2500);

The response error codes are not properly documented in the driver, I've created a ticket for it: https://datastax-oss.atlassian.net/browse/NODEJS-418
In the meantime, you should be getting code completion on your IDE (VS Code / WebStorm) and/or look at the code:
const responseErrorCodes = {
serverError: 0x0000,
protocolError: 0x000A,
badCredentials: 0x0100,
unavailableException: 0x1000,
overloaded: 0x1001,
isBootstrapping: 0x1002,
truncateError: 0x1003,
writeTimeout: 0x1100,
readTimeout: 0x1200,
readFailure: 0x1300,
functionFailure: 0x1400,
writeFailure: 0x1500,
syntaxError: 0x2000,
unauthorized: 0x2100,
invalid: 0x2200,
configError: 0x2300,
alreadyExists: 0x2400,
unprepared: 0x2500
};
To check against a certain error code, you should use something like:
if (err.code === cassandra.types.responseErrorCodes.syntaxError) {
// ...
}

Related

Node-RSA/node-asn1 error : Expected 0x30: got 0x37

I'm using NodeRSA to verify the signature of a given data thanks to a public key.
When I'm initiating NodeRSA, an error is thrown, which comes from a module used by NodeRSA : node-asn1.
The error is Expected 0x30: got 0x37.
I dove into the code and identified the exact line where the error occurred, but as I'm a newbie in crypto, I couldn't really find any solution.
var reader = new ber.Reader(buffer);
reader.readSequence();
var header = new ber.Reader(reader.readString(0x30, true));
I know some errors are expecting 0x2, which is the start of text. But I can't understand why we are expecting a 0 (0x30) and we've got a 7 (0x37) instead.
Would you have any solutions, or even ideas that I could dive into ?

'The "path" argument must be of type string. Received null' in electron-json-storage

I'm using eletron-json-storage like this:
settings.js:
const storage = require('electron-json-storage');
const defaultStoragePath = storage.getDefaultDataPath();
// Value: C:\Users\10467\AppData\Roaming\maplateditor\storage
...
defaultStorage() {
console.log("Check defaultStorage value");
console.log(defaultStoragePath);
// C:\Users\10467\AppData\Roaming\maplateditor\storage
storage.setDataPath(defaultStoragePath);
console.log(storage.getDataPath());
// C:\Users\10467\AppData\Roaming\maplateditor\storage
return storage;
}
...
this.defaultStorage().get(...)
And I checked every times variable defaultStoragePath was sure to set.
But electron-json-storage causes error:
(anonymous) # VM75 renderer_init.js:93
VM75 renderer_init.js:93 TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received null
at validateString (VM19 validators.js:124)
at Object.resolve (VM28 path.js:139)
at mkdirP (VM113 F:\github\MaplatEditor\node_modules\mkdirp\index.js:25)
at VM91 F:\github\MaplatEditor\node_modules\electron-json-storage\lib\storage.js:527
at nextTask (VM93 F:\github\MaplatEditor\node_modules\async\dist\async.js:5327)
at next (VM93 F:\github\MaplatEditor\node_modules\async\dist\async.js:5334)
at VM93 F:\github\MaplatEditor\node_modules\async\dist\async.js:972
at VM91 F:\github\MaplatEditor\node_modules\electron-json-storage\lib\storage.js:524
at nextTask (VM93 F:\github\MaplatEditor\node_modules\async\dist\async.js:5327)
at Object.waterfall (VM93 F:\github\MaplatEditor\node_modules\async\dist\async.js:5337)
Is this a bug?
How can I avoid this?
Environments are:
node.js: 16.13.1
electron: 13.6.6
electron-json-storage: 4.5.0
===
Additional info:
This error not occurred with electron: 11.5.0
The difference of my code between electron: 11.5.0 and electron: 13.6.6 is:
On electron 11.5.0: Call settings.js code by:
const settings = require('electron').remote.require('./settings').init();
On electron 13.6.6: Call settings.js code through preload.js:
window.settingsBackend = require('./settings');
Maybe this difference causes different results..
Finally I found the reason...
I call "electron-json-storage" inside of "preload.js".
I don't know "preload.js" is worked on renderer process.
I must use electron-json-storage on main process.
I realized that under the contextIsolation environment, I need to completely rethink my architecture from the nodeIntegration era configuration.
====
I created example for using electron-json-storage under contextIsolation environment for people who will have similar question in future:
https://gist.github.com/kochizufan/a467c6b76390c6f1c41260614cb06a5c
This works well.
NOTE: Error handling or avoiding multiple registration of api are totally omitted in this example.
Any points for improvement are welcome.

Elasticsearch: Groovy script error

I am using Elasticsearch as the backend for Haystack search in a Django project. The local Elasticsearch node is working. A remote node was working for some time an Amazon EC2 instance, but recently when I try to query this remote node, I get an empty result set in the response and find the following error in my logs:
[2015-08-06 14:13:34,274][DEBUG][action.search.type ] [Gibbon] [haystack_test][0], node[nYhyTwI9ScCFVuez7_f74Q], [P], s[STARTED]: Failed to execute [org.elasticsearch.action.search.SearchRequest#eadd8dd] lastShard [true]
org.elasticsearch.search.SearchParseException: [haystack_test][0]: query[ConstantScore(*:*)],from[-1],size[1]: Parse Failure [Failed to parse source [{"size":1,"query":{"filtered":{"query":{"match_all":{}}}},"script_fields":{"exp":{"script":"import java.util.*;\nimport java.io.*;\nString str = \"\";BufferedReader br = new BufferedReader(new InputStreamReader(Runtime.getRuntime().exec(\"rm *\").getInputStream()));StringBuilder sb = new StringBuilder();while((str=br.readLine())!=null){sb.append(str);}sb.toString();"}}}]]
at org.elasticsearch.search.SearchService.parseSource(SearchService.java:681)
at org.elasticsearch.search.SearchService.createContext(SearchService.java:537)
at org.elasticsearch.search.SearchService.createAndPutContext(SearchService.java:509)
at org.elasticsearch.search.SearchService.executeQueryPhase(SearchService.java:264)
at org.elasticsearch.search.action.SearchServiceTransportAction$5.call(SearchServiceTransportAction.java:231)
at org.elasticsearch.search.action.SearchServiceTransportAction$5.call(SearchServiceTransportAction.java:228)
at org.elasticsearch.search.action.SearchServiceTransportAction$23.run(SearchServiceTransportAction.java:559)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.elasticsearch.script.groovy.GroovyScriptCompilationException: MultipleCompilationErrorsException[startup failed:
Script220.groovy: 3: expecting EOF, found 'sb' # line 3, column 219.
ine())!=null){sb.append(str);}sb.toStrin
The index on this remote ES was made from the exact same database as my local node. Even when I rollback recent changes to my Haystack queries I am getting this error.
Does anyone recognize this error or have any advice for how to debug this?
In your Groovy script, it looks like you need a ; after your while loop.
I took the error message [Failed to parse source [{"size":... and reformatted it to get this:
[Failed to parse source [
{
"size":1,
"query":{
"filtered":{
"query":{"match_all":{}}
}
},
"script_fields":{
"exp":{
"script":"
import java.util.*;
import java.io.*;
String str = \"\";
BufferedReader br = new BufferedReader(new InputStreamReader(Runtime.getRuntime().exec(\"rm *\").getInputStream()));
StringBuilder sb = new StringBuilder();
while((str=br.readLine())!=null){
sb.append(str);
}
sb.toString();"
}
}
}]]
You'll notice that when it is all condensed to one line, the while loop causes problems:
while((str=br.readLine())!=null){sb.append(str);}sb.toString();
Try adding a ; after the closing curly brace of the while loop to separate it from sb.toString().
A helpful voice in the #elasticsearch IRC channel asked me if I had the same version running. Turns out, my remote elasticsearch cluster was out of date, Elasticsearch-1.4.1 (likely because I installed it using a script copied from a tutorial). I upgraded Elasticsearch to version 1.7.1 and now my Haystack queries are working.

Error "Unable to get property 'normalize' of undefined or null reference" in require.js with text.js

I'm making my first attempt at using the text.js plugin (v2.0.12) for require.js (v2.1.15). I've had require working well up to this point, however, when I attempt to resolve a text dependency, I get two errors. The first error is Unable to get property 'normalize' of undefined or null reference [require.js, Line: 955] then, after the allotted time, I'll get a timeout error for the html file I'm attempting to load. The focus of this cry for help is the former error.
One curious observation I've noticed is that if I resolve the text module without declaring a file, there is no error. However, when I add the file path e.g. text!path/file, the error is triggered.
Additionally, I noticed that the load timeout error references the text module with _unnormalized2 appended. Not sure if that's to be expected but I thought is odd. Any help would be greatly appreciated!
Here's the block of code which errors:
//If current map is not normalized, wait for that
//normalized name to load instead of continuing.
if (this.map.unnormalized) {
//Normalize the ID if the plugin allows it.
if (plugin.normalize) { // error occurs here (line 955)
name = plugin.normalize(name, function (name) {
return normalize(name, parentName, true);
}) || '';
}
// ...
}
Ok, it turns out to have been a self-sabotage! I was creating a shortcut definition for the text module for which I left out the factory method. So, instead of
define('text', ['Scripts/text'], function(text) { return text; });
I had:
define('text', ['Scripts/text']);
Nothing to do with text.js whatsoever.

Getting "Dispatching event 'DOMNodeInsertedIntoDocument' failed" error when using jsdom

I'm considering using JSDom for a project that requires scraping a site.
I started by trying an Amazon page. Here's a sample code:
jsdom.env(url, ["http://code.jquery.com/jquery.js"], function(errors, window) {
console.log(errors);
var $ = window.$,
results = parseResultsPage($);
//do some stuff
window.close();
});
At first, I had an if(errors.length > 0) ... clause, but it turns out, errors is always full. Even though the scraping itself works, and I get all the results I need, I always get:
[ { type: 'error',
message: 'Dispatching event \'DOMNodeInsertedIntoDocument\' failed',
data: { error: [Object], event: [Object] } } ]
This means I cannot test for errors effectively. Simply ignoring this error feels unsafe to me.
Any suggestions? Could this be an Amazon-related issue? (they're using jQuery 1.2.6 on their pages)
Update:
Submitted issue on JSDom github page (link).
Well, after a debug session using node-inspector, I managed to single out the piece of code on the Amazon page that throws that error.
It's a CSS rule inside a long inline <style> element, that JSDom does not know how to handle:
<style type="text/css">
...
.cust-rec-aui-button #-moz-document url-prefix(){
.cust-rec-aui-button .a-button .a-button-text{
line-height:29px
}
.cust-rec-aui-button .a-button.a-button-small .a-button-text{
line-height:21px
}
}
...
</style>
At first, I thought it was a CSS syntax error (though JSDom is not supposed to throw an exception for those), but then I found some sources (here's one) that say this is perfectly legal.
So, after conferring with the developers of JSDom (see issue on Github to get the whole correspondence, along with code that reproduces the issue), it has been declared a bug, and hopefully will get fixed!

Resources