So I have a rust contract that has a storage mapper for an arbitrary value. I store it based on a identifier which is an u64.
#[view(getVersion)]
#[storage_mapper("someValue")]
fn get_value(&self, identifier:u64) -> SingleValueMapper<u64>
When I query this using the API or erdJs I always get
{
"statusCode": 400,
"code": "user error",
"message": "storage decode error: input too short"
}
What am I doing wrong?
So what I was doing wrong here was not the code of the contract itself but rather I was calling a query for a value that was not stored.
I was trying to reach a value that was not set in my case. For example I had these values
1 -> 100
2 -> 200
3 -> 300
5 -> 500
notice how identifier "4" does not have any reference stored. So I was trying to query this view for the identifier "4" and therefore I was getting a storage decode error because the storage was empty for that value.
Related
My department uses the olivere elastic v7.0.26 as ElasticSearch Client,sometimes our front-end system returns some errormsg such as "Error 400 (Bad Request): all shards failed [type=search_phase_execution_exception]" but doesn't have any other useful msg to help troubleshooting,so I've searched GitHub about parsing errors to *elastic.Error and codes are just like this:
if err != nil {
log.WithFields(ctx, log.Fields{}).WithError(err).Warn("list query es error")
if ex, ok := err.(*elastic.Error); ok {
log.WithFields(ctx, log.Fields{"query": query, "status": ex.Status, "detail": ex.Details}).WithError(ex).Warnf("list query es err")
}
return res, err
}
But the strange thing happened is "list query es error" was printed on our log system but the next log "list query es err" didn't,i've used deep-paging (large from+size) to check the log,it works and print the elastic error such as root cause so i can get the max_result_window tips..But it returns a unparsing error which is returned as the search_phase_execution_exception error,the company code is not allowed to paste to the open-sourcing website,and I just wanna know what error can make elasticsearch returns the search_phase_execution_exception and the errcode 400?Really appreciate your help!
same to above description,but the point I need to supple is that the problem is not always happened,so I can exclude the index mapping field type error such as "text/keyword",just wanna get the whole error/exceptions elasticsearch can return,but I cannot find the relative documentions on elastic guide,that's ok if u can provide the guide/doc about this
uhh it seems like a joke XD,I've never learned about some troubleshooting technique,but after I asked this question,I realized that I can get the ElasticSearch server log,so I asked our company's SRE and got the log,it's a error about terms query exceed maximum,and the reason caused is our RPC interface return a exceptional result about nil data redis set key,it will be a big-key problem,but we found this and fix it.
I'm trying to reindex data from an old cluster to a new one
During the process I'm facing the following issue:
Validation Failed: 1: id is too long, must be no longer than 512 bytes but was: 532;
id here is a string field
a. My first attempt was to add "conflicts": "proceed" to the request body of reindex API. But that did not work and I faced same issue again
b. Then I tried to filter using below clause, idea was to delete them from old cluster:
doc['_id'].toString().getBytes().length > 512
But this fails due to below error:
"caused_by" : {
"type" : "illegal_argument_exception",
"reason" : "dynamic method [java.lang.String, getBytes/0] not found"
}
Is there any other workaround for this?
I'm receiving this mysterious error message when using a custom virtual entity data provider:
{
"error": {
"code": "0x80040216",
"message": "An unexpected error occurred.",
"#Microsoft.PowerApps.CDS.ErrorDetails.ApiExceptionSourceKey": "Plugin/Microsoft.Crm.ObjectModel.InsertLookupLogicalNamePlugin",
"#Microsoft.PowerApps.CDS.ErrorDetails.ApiStepKey": "ccb4d064-785c-eb11-a812-002248163c60",
"#Microsoft.PowerApps.CDS.ErrorDetails.ApiDepthKey": "1",
"#Microsoft.PowerApps.CDS.ErrorDetails.ApiActivityIdKey": "aac514e1-53ec-4ed9-9e47-d2643f0e92b1",
"#Microsoft.PowerApps.CDS.ErrorDetails.ApiPluginSolutionNameKey": "System",
"#Microsoft.PowerApps.CDS.ErrorDetails.ApiStepSolutionNameKey": "System",
"#Microsoft.PowerApps.CDS.ErrorDetails.ApiExceptionCategory": "SystemFailure",
"#Microsoft.PowerApps.CDS.ErrorDetails.ApiExceptionMesageName": "UnExpected",
"#Microsoft.PowerApps.CDS.ErrorDetails.ApiExceptionHttpStatusCode": "400",
"#Microsoft.PowerApps.CDS.HelpLink": "http://go.microsoft.com/fwlink/?LinkID=398563&error=Microsoft.Crm.CrmException%3a80040216&client=platform",
"#Microsoft.PowerApps.CDS.TraceText": "\r\n[Microsoft.Crm.ObjectModel: Microsoft.Crm.ObjectModel.InsertLookupLogicalNamePlugin]\r\n[ccb4d064-785c-eb11-a812-002248163c60: External plug-in implementation]\r\n\r\n",
"#Microsoft.PowerApps.CDS.InnerError.Message": "An unexpected error occurred."
}
}
It seems to occur more often with larger page sizes.
Plugin trace logs indicate the data provider ran successfully/no exception.
After some spelunking I found this error message in the on-prem server:
Query with entity reference to virtual entity can not exceed 250 limit. Please modify your query to reduce the number.
The limit appears to be unique lookup field values across the whole query. So in this example, if the results were as below:
Record
Lookup Column to Virtual Entity
Lookup Column to Virtual Entity
1
Value A
Value B
2
Value C
3
Value A
Value C
Would count as 3 towards the limit for that query.
Hi I am getting the below error in polkadot-js, when I am trying to transfer the balance from Alice to Dave (or any other transfer).
Error :
balances.transferKeepAlive
1002: Verification Error: Execution: Could not convert parameter tx between node and runtime: No such variant in enum MultiSignature: RuntimeApi, Execution: Could not convert parameter tx between node and runtime: No such variant in enum MultiSignature
Please refer the screen shot in the below :
Screen Shot
You are missing some data types on your UI, adding this in developer settings will do the job.
{
"Address": "MultiAddress",
"LookupSource": "MultiAddress"
}
https://polkadot.js.org/docs/api/FAQ#the-node-returns-a-could-not-convert-error-on-send
{
"Address": "MultiAddress",
"LookupSource": "MultiAddress"
}
Worked for me on the Substrate - Forkless Upgrade a Chain tutorial: https://substrate.dev/docs/en/tutorials/forkless-upgrade/sudo-upgrade
https://polkadot.js.org/apps/?rpc=ws%3A%2F%2F127.0.0.1%3A9944#/settings/developer -> Settings - Developer - change the JSON to match the above -> Save, that's it.
When I run this code:
$client->evaluate('
box.session.settings.error_marshaling_enabled = false
box.error{code = 42, reason = "Foobar", type = "MyError"}
');
regardless of the value of error_marshaling_enabled I always get a response with a new (extended) error format:
[
49 => 'Foobar',
82 => [
0 => [
0 => [
0 => 'CustomError',
2 => 3,
1 => 'eval',
3 => 'Foobar',
4 => 0,
5 => 42,
6 => [
'custom_type' => 'MyError',
],
],
],
],
],
Why is that?
Short answer.
error_marshaling_enabled option affects only how error objects are encoded in response body (48, IPROTO_DATA). It does not affect how they are returned as exceptions, in the response header (82, IPROTO_ERROR).
Long answer.
In Tarantool an error object can be returned in 2 ways: as an exception and as an object. For example, this is how to throw an error as exception:
function throw_error()
box.error({code = 1000, reason = "Error message"})
-- Or
error('Some error string')
end
This is how to return it as an object:
function return_error()
return box.error.new({code = 1000, reason = "Error message"})
end
If the function was called remotely, using IPROTO protocol via a connector like netbox, or PHP connector, or any other one, the error return way affects how it is encoded into MessagePack response packet. When the function throws, and the error reaches the top stack frame without being caught, it is encoded as IPROTO_ERROR (82) and IPROTO_ERROR_24 (49).
When the error object is returned as a regular value, not as an exception, it is encoded also as a regular value, inside IPROTO_DATA (48). Just like a string, a number, a tuple, etc.
With encoding as IPROTO_ERROR/IPROTO_ERROR_24 there is no much of a configuration space. Format of these values can't be changed. IPROTO_ERROR is always returned as a MessagePack map, with a stack of errors in it. IPROTO_ERROR_24 is always an error message. The IPROTO_ERROR_24 field is kept for compatibility with connectors to Tarantool versions < 2.4.1.
With encoding as a part of IPROTO_DATA you can choose serialization way using error_marshaling_enabled option. When it is true, errors are encoded as MessagePack extension type MP_EXT, and contain the whole error stack, encoded exactly like IPROTO_ERROR value. When the option is false (default behaviour in 2.4.1), the error is encoded as a string, MP_STR, which is the error's message. If there is a stack of errors, only the newest error is encoded.
error_marshaling_enabled option exists for backward compatibility, in case your application on Tarantool wants to be compatible with old connectors, which don't support MP_EXT encoded errors.
In Tarantool < 2.4.1 errors were encoded into result MessagePack as a string with error message, and error stacks didn't exist at all. So when the new format and the error stacks feature were introduced, making the new format default would be a too radical change breaking the old connectors.
Consider these examples of how error marshaling affects results. I use Tarantool 2.4.1 console here, and built-in netbox connector. The code below can be copy pasted into the console.
First instance:
box.cfg{listen = 3313}
box.schema.user.grant('guest', 'super')
function throw_error()
box.error({code = 1000, reason = "Error message"})
end
function return_error()
return box.error.new({code = 1000, reason = "Error message"})
end
Second instance:
netbox = require('net.box')
c = netbox.connect(3313)
Now I try to call the function on the second instance:
tarantool> c:call('throw_error')
---
- error: Error message
...
The c:call('throw_error') threw an exception. If I catch it using pcall() Lua function, I will see the error object.
tarantool> ok, err = pcall(c.call, c, 'throw_error')
tarantool> err:unpack()
---
- code: 1000
base_type: ClientError
type: ClientError
message: Error message
trace:
- file: '[string "function throw_error()..."]'
line: 2
...
As you can see, I didn't set error_marshaling_enabled, but got the full error. Now I will call the other function, without exceptions. But the error object won't be full.
tarantool> err = c:call('return_error')
tarantool> err
---
- Error message
...
tarantool> err:unpack()
---
- error: '[string "return err:unpack()"]:1: attempt to call method ''unpack'' (a nil
value)'
...
The error was returned as a mere string, error message. Not as an error object. Now I will turn on the marshaling:
tarantool> c:eval('box.session.settings.error_marshaling_enabled = true')
---
...
tarantool> err = c:call('return_error')
---
...
tarantool> err:unpack()
---
- code: 1000
base_type: ClientError
type: ClientError
message: Error message
trace:
- file: '[C]'
line: 4294967295
...
Now the same function returned the error in the new format, more featured.
On the summary: error_marshaling_enabled affects only returned errors. Not thrown errors.