When the realtime model gets too big, for whatever reason, the realtime client throws an error something like:
"Error: Class$S383: Model size limit has been exceeded. Used: 10486181 bytes; Limit: 10485760 bytes at... "
As far as I know, there isn't a documented gapi.drive.realtime.ErrorType that matches, so currently I'm using the following to identify it:
try {
changeModelInSomeWay(rtModel);
} catch (e) {
if (e && e.message && e.message.indexOf("Class$S383") > -1) {
// Model is just too darn big:
doSomething();
} else {
doSomethingElse(e);
}
};
...which seems to work for now, but feels fragile, prone-to-change etc.
UPDATE:
Yep, it IS fragile, I've now seen the identical error except with the class Class$S390 instead. If there's anyone still monitoring the Realtime API tag, some sort of answer would be really appreciated...
What's the correct, or at least a reliable way to identify this error?
Related
=== SAD PANDA ===
TypeError: Failed to fetch
=== SAD PANDA ===
While executing a flow cadence transaction in react.js, I got the above error.
My intention is when I click the minttoken button, this transaction has to execute so as to mint the NFT.
const mintToken = async() => {
console.log(form.name)
const encoded = await fcl.send([
fcl.proposer(fcl.currentUser().authorization),
fcl.payer(fcl.authz),
fcl.authorizations([fcl.authz]),
fcl.limit(50),
fcl.args([
fcl.arg(form.name,t.String),
fcl.arg(form.velocity,t.String),
fcl.arg(form.angle,t.String),
fcl.arg(form.rating,t.String),
fcl.arg(form.uri,t.String)
]),
fcl.transaction`
import commitContract from 0xf8d6e0586b0a20c7
transaction {
let receiverRef: &{commitContract.NFTReceiver}
let minterRef: &commitContract.NFTMinter
prepare(acct: AuthAccount) {
self.receiverRef = acct.getCapability<&{commitContract.NFTReceiver}>(/public/NFTReceiver)
.borrow()
?? panic("Could not borrow receiver reference")
self.minterRef = acct.borrow<&commitContract.NFTMinter>(from: /storage/NFTMinter)
?? panic("could not borrow minter reference")
}
execute {
let metadata : {String : String} = {
"name": name,
"swing_velocity": velocity,
"swing_angle": angle,
"rating": rating,
"uri": uri
}
let newNFT <- self.minterRef.mintNFT()
self.receiverRef.deposit(token: <-newNFT, metadata: metadata)
log("NFT Minted and deposited to Account 2's Collection")
}
}
`
]);
await fcl.decode(encoded);
}
this error being so useless is my fault, but I can explain what is happening here because it also only happens in a really specific situation.
Sad Panda error is a catch all error that happens when there is a catastrophic failure when fcl tries to resolve the signatures and it fails in a completely unexpected way. At the time of writing this it usually shows up when people are writing their own authorization functions so that was the first thing i looked at in your code example. Since you are using fcl.authz and fcl.currentUser().authorization (both of those are the same by the way) your situation here isnt because of a custom authorization function, which leads me to believe this is either a configuration issue (fcl.authz is having a hard time doing its job correctly) or what fcl is getting back from the wallet doesn't line up with what it is expecting internally (most likely because of an out of date version of fcl).
I have also seen this come up when the version of the sdk that fcl uses doesnt line up with the version of the sdk that is there (because some people have added #onflow/sdk as well as #onflow/fcl) so would also maybe check to make sure you only have fcl in your package.json and not the sdk as well (everything you should need from the sdk should be exposed from fcl directly, meaning you shouldnt need the sdk as a direct dependency of your application)
I would first recommend making sure you are using the latest version of fcl (your code should still all work), then i would make sure you are only using fcl and not inadvertently using an older version of the sdk. If you are still getting the same error after that could you create an issue on the github so we can dedicate some resources to helping sort this out (and make it so you and others dont see this cryptic error in future versions of fcl)
The IndexBatchException documentation, e.g., when calling IndexAsync, states:
Thrown when some of the indexing actions failed, but other actions succeeded and modified the state of the index. This can happen when the Search Service is under heavy indexing load. It is important to explicitly catch this exception and check its IndexResult property. This property reports the status of each indexing action in the batch, making it possible to determine the state of the index after a partial failure.
Does this mean this exception can be safely ignored when there is just a single document in the IndexBatch? Since, it seems impossible for an IndexBatch with just a single document to fail partially.
I tried calling IndexAsync with a Merge batch containing a single document to update, but with a non-existing document key (as recommended by Bruce):
var nonExistingDocument = SomeDocument()
var work = IndexBatch.Merge( nonExistingDocument );
try
{
await _search.Documents.IndexAsync( work );
}
catch ( IndexBatchException e )
{
var toRetry = e.FindFailedActionsToRetry( work, d => d.Id);
}
IndexBatchException was triggered, which is different behavior than what is documented in two ways:
"Thrown when some of the indexing actions failed, but other actions succeeded and modified the state of the index." Instead, the exception is thrown when any action fails.
"This can happen when the Search Service is under heavy indexing load." This can also happen for incorrect requests.
But, FindFailedActionsToRetry is seemingly smart enough to not suggest retrying requests which have failed due to erroneous requests. The toRetry enumeration is empty in the code sample above.
In short, no, this exception cannot be safely ignored. The documentation is misleading and it would be nice if it were updated.
Have a very strange intermittent problem, and one that I just can not understand at all. Not certain it is code related, bug in express or just me missing something.
Have an app, all in MEAN, that like so many other apps around does a bunch of API calls. Some even in parallel.
It all worked perfect this morning, actually, read the "where it gets weird", but then all of a sudden it stops working and the server starts falling over with the below error:
GET /api/skillList 304 45.345 ms - -
_http_outgoing.js:335
throw new Error('Can\'t set headers after they are sent.');
^
Error: Can't set headers after they are sent.
at ServerResponse.OutgoingMessage.setHeader (_http_outgoing.js:335:11)
at ServerResponse.header (/Users/bengtbjorkberg/WebstormProjects/ResourceEdge/node_modules/express/lib/response.js:695:10)
at ServerResponse.json (/Users/bengtbjorkberg/WebstormProjects/ResourceEdge/node_modules/express/lib/response.js:232:10)
at /Users/bengtbjorkberg/WebstormProjects/ResourceEdge/routes/api.js:78:9
at /Users/bengtbjorkberg/WebstormProjects/ResourceEdge/node_modules/mongoose/node_modules/kareem/index.js:160:11
at Query._findOne (/Users/bengtbjorkberg/WebstormProjects/ResourceEdge/node_modules/mongoose/lib/query.js:1145:12)
at /Users/bengtbjorkberg/WebstormProjects/ResourceEdge/node_modules/mongoose/node_modules/kareem/index.js:156:8
at /Users/bengtbjorkberg/WebstormProjects/ResourceEdge/node_modules/mongoose/node_modules/kareem/index.js:18:7
at process._tickCallback (node.js:355:11)
Process finished with exit code 1
What I have checked.
Threw tons of log messages, looks like it falls over at different places, or I am missing one of the places
Spent a lot of time looking at the last call (/api/skilllist), to be working quite OK.
Where it gets REALLY weird
If I start the developer console in Chrome, the problem DOES NOT OCCURE, which is probably why it worked all day but then stopped working when I wanted to show it to someone...
While I was writing this, I realised that I could use safari, and it falls over with the java console on, and it is the same line server side. And its the database call below. But if I turn the console on in Chrome, it starts working... What am I missing
exports.canlist = function (req, res) {
// use mongoose to get all profiles in the database
console.log("Canlist called");
Profile.find( {}, {'_id':1, 'alias':1, 'img':1, 'summary':1, 'keys':1}, function(err, profiles) {
// if there is an error retrieving, send the error. nothing after res.send(err) will execute
if (err) {
console.log("Error " + err)
res.send(err)
}
console.log("Sending back " + profiles.length + " profiles")
res.json(profiles); // return all todos in JSON format
});
};
So, after much faffing about, I figured it out. Not why it works when using java console it open on Chrome.
Basically the res.send(err) command is wrong.
First its missing return.
Secondly I THINK you are suppose to use the longer form like this:
return res.status(500).send(err);
return res.json(profile);
Think the problem was that it was confusing express, which probably do some pre processing, which may explain why it "seems" to blow up at all kind of times.
(Would have kept quiet about this, as it is a bit of a ridiculous mistake, but it saves someone a few hours staring at the screen I might get a christmas card this year. (or at least get to tell santa that I've been a good boy)
I am trying to do a simple query against a Cassandra cluster using the Node.js Cassandra driver. I am following the examples, but it seems like my callback functions are getting called even if there are no results in the returned set.
var q = function (param) {
var query = 'SELECT * FROM my_table WHERE my_col=?';
var params = [param];
console.log("Cassandra query is being called with parameters " + params);
client.execute(query, params, function (err, result) {
console.log("Cassandra callback is being called. Row count is " + result.rows.length);
if (err != null) {
console.log("Got error");
}
if (result.rows.length <= 0) {
console.log("Sending empty response.");
}
else {
console.log("Sending non-empty response.");
}
});
};
q('value');
q('value');
Outputs
Cassandra query is being called with parameters value
Cassandra query is being called with parameters value
Cassandra callback is being called. Row count is 0
Sending empty response.
Cassandra callback is being called. Row count is 1
Sending non-empty response.
This is happening fairly consistently, but sometimes both calls will come up empty, and sometime both calls will return values.
I guess I'm doing something wrong with the async calls here, but I'm not really sure what it is.
I think this was due to a bad node in my cluster. One of the nodes was missing a bunch of data, and so one third of the time I would get back no results.
When you open the connection do you send down a consistency command?
I had this issue as well, when I open a connection call execute and send use <keyspace>; followed by consistency local_quorum;. This tells Cassandra to look a little harder for the answer and agree with other nodes that you are getting the latest version.
Note: I keep my connections around for a while, so this doesn't add any meaningful overhead (for me).
Note2: The above doesn't seem to work from my python app anymore (using Cassandra 3.5). However, using SimpleStatement and setting the consistency before calling execute does: https://datastax.github.io/python-driver/getting_started.html#setting-a-consistency-level
I hope this helps.
Due to the async nature of http access via WebClient or HttpWebRequest in Silverlight 4, when I want to do multiple http get/posts serially, I find myself writing code that looks like this:
doFirstGet(someParams, () =>
{
doSecondGet(someParams, () =>
{
doThirdGet(...
}
});
Or something similar. I'll end up nesting subsequent calls within callbacks usually implemented using lambdas of some sort. Even if I break things out into Actions or separate methods, it still ends up being hard to read.
Does anyone have a clean solution to executing multiple http requests in SL 4 serially?
I don't need the code that actually kicks all of this off to be synchronous, but I need the requests to happen serially, so each request needs to be effectively synchronous.
Take look at a couple of my blog posts on this:-
Simple Asynchronous Operation Runner – Part 1
Simple Asynchronous Operation Runner – Part 2
The articles are a little in depth because they focus on the actual implementation, the idea is not have to include fancy frameworks just to get this done. The only code you need is actually there in the articles, no additional dlls or zip files to download.
However note in part 2 the approach of imagining what your code would look like if synchronous coding were possible. In your case your code would look like this:-
void StuffToDo()
{
doFirstGet(someParams);
doSecondGet(someParams);
doThirdGet(...);
}
The next step is modify the content of the "do" methods to return an AsyncOperation instead. Currently they probably look something like this:-
void doFirst(someParams, Action callback)
{
SomeAsyncObj thing = new SomeAsyncObj();
thing.OnCompleted += (s, args) { callback() };
thing.DoSomethingAsync();
}
You would convert it to:-
AsyncOperation doFirst(someParams)
{
return (completed) =>
{
SomeAsyncObj thing = new SomeAsyncObj();
thing.OnCompleted += (s, args) =>
{
try
{
completed(null);
}
catch (Exception err)
{
completed(err);
}
};
thing.DoSomethingAsync(source);
};
}
The third step is modify your imaginary synchronous code like this:-
IEnumerable<AsyncOperation> StuffToDo()
{
yield return doFirstGet(someParams);
// Do some other synchronous stuff here, this code won't run until doFirstGet has completed.
yield return doSecondGet(someParams);
// Do some other synchronous stuff here, this code won't run until doSecondGethas completed.
yield return doThirdGet(...);
// Do some final synchronous stuff here, this code won't run until doThirdGethas completed.
}
Finally the call to StuffToDo changes to:-
StuffToDo().Run((err) =>
{
// report any error in err sensibly
});
I have encountered this problem. I found coroutines to be very helpful, I based my ideas on work by Jeremy Likness and Rob Eisenberg.
This link will give more details.
Encapsulate each request into a class
Create a collection or array of the requests
Iterate through the collection making and processing each request.