we run the nplb test both on the x86-x11 and arm-linux plarform with cobalt Release 11.104700 version, the SbSocketGetInterfaceAddressTest test would both fail, so it seemed to be the issue of NPLB itself, can someone have a look?
[ FAILED ] SbSocketAddressTypes/SbSocketGetInterfaceAddressTest.SunnyDayDestination/1, where GetParam() = 1
[ FAILED ] SbSocketAddressTypes/SbSocketGetInterfaceAddressTest.SunnyDaySourceForDestination/1, where GetParam() = 1
[ FAILED ] SbSocketAddressTypes/SbSocketGetInterfaceAddressTest.SunnyDaySourceNotLoopback/1, where GetParam() = 1
1>SbSocketAddressTypes/SbSocketGetInterfaceAddressTest.SunnyDayDestination/1
../../starboard/nplb/socket_get_interface_address_test.cc:85: Failure
Value of: SbSocketGetInterfaceAddress(&destination, &source, NULL)
Actual: false
Expected: true
../../starboard/nplb/socket_get_interface_address_test.cc:86: Failure
Value of: source.type == GetAddressType()
Actual: false
Expected: true
../../starboard/nplb/socket_get_interface_address_test.cc:87: Failure
Value of: SbSocketGetInterfaceAddress(&destination, &source, &netmask)
Actual: false
Expected: true
../../starboard/nplb/socket_get_interface_address_test.cc:93: Failure
Value of: GetAddressType()
Actual: 1
Expected: source.type
Which is: 4278124286
../../starboard/nplb/socket_get_interface_address_test.cc:94: Failure
Value of: GetAddressType()
Actual: 1
Expected: netmask.type
Which is: 4278124286
../../starboard/nplb/socket_get_interface_address_test.cc:95: Failure
Value of: 0
Expected: source.port
Which is: -16843010
2>SbSocketAddressTypes/SbSocketGetInterfaceAddressTest.SunnyDaySourceForDestination/1
[13672:19284243583:ERROR:socket_connect.cc(52)] SbSocketConnect: connect failed: 101
../../starboard/nplb/socket_get_interface_address_test.cc:128: Failure
Value of: source.type == GetAddressType()
Actual: false
Expected: true
../../starboard/nplb/socket_get_interface_address_test.cc:132: Failure
Value of: GetAddressType()
Actual: 1
Expected: netmask.type
Which is: 4278124286
../../starboard/nplb/socket_get_interface_address_test.cc:134: Failure
Expected: (0) != (SbMemoryCompare(source.address, invalid_address.address, (sizeof(source.address) / sizeof(source.address[0])))), actual: 0 vs 0
../../starboard/nplb/socket_get_interface_address_test.cc:136: Failure
Expected: (0) != (SbMemoryCompare(netmask.address, invalid_address.address, (sizeof(netmask.address) / sizeof(netmask.address[0])))), actual: 0 vs 0
3>SbSocketAddressTypes/SbSocketGetInterfaceAddressTest.SunnyDaySourceNotLoopback/1
../../starboard/nplb/socket_get_interface_address_test.cc:165: Failure
Value of: SbSocketGetInterfaceAddress(&destination, &source, NULL)
Actual: false
Expected: true
../../starboard/nplb/socket_get_interface_address_test.cc:166: Failure
Value of: GetAddressType()
Actual: 1
Expected: source.type
Which is: 4278124286
../../starboard/nplb/socket_get_interface_address_test.cc:167: Failure
Value of: SbSocketGetInterfaceAddress(&destination, &source, &netmask)
Actual: false
Expected: true
../../starboard/nplb/socket_get_interface_address_test.cc:172: Failure
Expected: (0) != (SbMemoryCompare(netmask.address, invalid_address.address, (sizeof(netmask.address) / sizeof(netmask.address[0])))), actual: 0 vs 0
../../starboard/nplb/socket_get_interface_address_test.cc:174: Failure
Expected: (0) != (SbMemoryCompare(source.address, invalid_address.address, (sizeof(source.address) / sizeof(source.address[0])))), actual: 0 vs 0
It looks like a number of SbSocket implementations in your Starboard port are broken and NPLB rightfully points it out.
For example, in order to pass SbSocketGetInterfaceAddressTest.SunnyDayDestination you need to follow the comment from SbSocketGetInterfaceAddress declaration:
// If the destination address is 0.0.0.0, and its |type| is
// |kSbSocketAddressTypeIpv4|, then any IPv4 local interface that is up and not
// a loopback interface is a valid return value.
and
// Returns whether it was possible to determine the source address and the
// netmask (if non-NULL value is passed) to be used to connect to the
// destination. This function could fail if the destination is not reachable,
// if it an invalid address, etc.
In other words, the test expects out_source_address to be an IP address of the machine and return value to be true.
Since you are seeing the same error on linux_x86-x11 build, I suggest you to verify that POSIX function connect (used by SbSocketConnect implementation on Linux) works well with 0.0.0.0 IP address on your platform.
Related
When calling http endpoint in GCP workflow, only HttpStatus 200 is considered a success.
How to handle other Success Status codes? 201, 202, etc.
Example workflow from samples:
- readItem:
try:
call: http.get
args:
url: https://example.com/someapi
auth:
type: OIDC
result: APIResponse
except:
as: e
steps:
- knownErrors:
switch:
- condition: ${not("HttpError" in e.tags)}
next: connectionProblem
- condition: ${e.code == 404}
next: urlNotFound
- condition: ${e.code == 403}
next: authProblem
- UnhandledException:
raise: ${e}
- urlFound:
return: ${APIResponse.body}
- connectionProblem:
return: "Connection problem; check URL"
- urlNotFound:
return: "Sorry, URL wasn't found"
- authProblem:
return: "Authentication error"
If the api endpoint https://example.com/someapi returns anything other than a 200 status code the connectionProblem is invoked.
This is the same if its a GET or POST request.
What is the best way of handling this?
There is nothing referencing how to handle other 200s statuses in the documentation for Google Workflows so I assume this is not possible without treating them as errors.
This means that in order to do it you are going to need to add an extra step to deal with this status as an error handling strategy, like - condition: ${e.code == 201} for example.
Alternatively you could open a feature request in Google's Issue Tracker so that they can consider implementing different treatements of such status codes or at least so that this is touched on more details in the documentation.
At present response codes >= 400 and <= 599 are considered an error and will raise an exception. i.e. 200s are considered a success and will not.
Alternatively, if you want to trigger an exception handler for return codes in this range (or for any other reason), this can be done by adding an additional step to the try call, for example (illustration only):
main:
steps:
- getStuff:
try:
steps:
- callStep:
call: http.get
args:
url: <SOME URL>
result: r
- checkNotOK:
switch:
- condition: ${r.code == 202}
raise: ${r}
retry:
predicate: ${custom_predicate}
max_retries: 5
backoff:
initial_delay: 2
max_delay: 60
multiplier: 2
custom_predicate:
params: [e]
steps:
- what_to_repeat:
switch:
- condition: ${e.code == 202}
return: true
- otherwise:
return: false
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.
I have a bash script that, among other things, runs a command. For context, it's running a unison profile for file synchronisation.
The script takes parameters which are passed to the unison function, like so (shortened)
#!/bin/bash
unisonparameters=$1
unisonresult=$( { unison $unisonparameters local; } )
if [ $? -ne 0 ]
then
<<send email using $unisonresult>>
fi
I'd like to be able, to run the script in 2 ways:
as a cronjob, in which case I pass the parameters that require no user interaction (-batch), and the scripts emails me in case there is an issue.
as a user-initiated action, in which case I pass no parameters, so that unison asks me what I want to do with the files it found. In this case I'm indifferent to whether or not an email is sent.
I was hoping the script above would work, but as discussed in the comments it does not. Is there a way to make it work?
Additional information 1
I've been trying to get the script to ask for user input if I pass no parameters (so that $unisonparameters = ''). Here are the results
Working
If dont try to save the output to a variable, like so:
unison $unisonparameters local
if [ $? -ne 0 ]
then
<<send email>>
fi
, all is run as expected and without error:
elrudi#dell:~$ ./syncnas.sh
Mon Oct 22 22:23:17 CEST 2018
Syncing data with nas.
Found a local device at 192.168.1.100 to connect to.
running command 'unison local'...
Contacting server...
Connected [//nas//share/HDA_DATA/elrudi -> //dell//home/elrudi]
Looking for changes
Waiting for changes from server
Reconciling changes
local nas
new dir ----> syncAll/newFolder
new file ---->
(...)
(first lines due to other parts in script.)
Broken
However, if I use the original line in the script above, trying to store the output of this command:
unisonresult=$( { unison $unisonparameters local; } )
if [ $? -ne 0 ]
then
<<send email>>
fi
, it hangs on the unison command:
elrudi#dell:~$ ./syncnas.sh
Mon Oct 22 22:01:17 CEST 2018
Syncing data with nas.
Found a local device at 192.168.1.100 to connect to.
running command 'unison local'...
Contacting server...
Connected [//nas//share/HDA_DATA/elrudi -> //dell//home/elrudi]
Looking for changes
Waiting for changes from server
Reconciling changes
Terminated!
(Last line caused by my eventual ctrl-c.)
Additional information 2
I've tried adding -debug verbose to the unison command to get some more information. In both cases the output is very long. The interesting part is at the end, which i'm showing below.
Working
In the first case, with unison $unisonparameters -debug verbose local the script eventually asks for user input regarding which files to sync in which direction:
(...)
[server: update+] Archive name is //nas//share/HDA_DATA/elrudi;//nas//share/HDA_DATA/elrudi, //xps//home/elrudi;22; hashcode is 1cee08d0fa648cd9d77332dc9623b39e
[server: remote+] Sending result (id: 16)
[server: remote+] send [unlockArchive-res] '\132\149\166\190\000\000\000\001\000\000...' 21 bytes
[server: remote+] send [rsp] '\132\149\166\190\000\000\000\001\000\000...' 21 bytes
[server: remote_emit+] dump: \016\000\000\000\246\024\000\000\000\233rsp\132\149\166\190\000\000\000\001\000\000\000\000\000\000\000\000\000\000\000\000#&\000\000\000\018unlockArchive-res\132\149\166\190\000\000\000\001\000\000\000\000\000\000\000\000\000\000\000\000#
[remote_emit+] grab: \016\000\000\000\246\024\000\000\000\233rsp\132\149\166\190\000\000\000\001\000\000\000\000\000\000\000\000\000\000\000\000#&\000\000\000\018unlockArchive-res\132\149\166\190\000\000\000\001\000\000\000\000\000\000\000\000\000\000\000\000#
[remote+] Message received (id: 16)
[remote+] receive 'rsp\132\149\166\190\000\000\000...' 24 bytes
[remote+] receive 'unlockArch...' 38 bytes
[remote+] Waiting for next message
(...)
[pred] preferpartial 'syncFolder/Software_Config/Linux/variety/Downloaded/Unsplash/photo-1535941863447-76a4dc94e2ba.jpg' = false
[pred] forcepartial 'syncFolder/Software_Config/Qnap/3_Unison/syncnas.sh' = false
[pred] preferpartial 'syncFolder/Software_Config/Qnap/3_Unison/syncnas.sh' = false
[pred] forcepartial 'syncFolder/test2.txt' = false
[pred] preferpartial 'syncFolder/test2.txt' = false
[pred] forcepartial 'syncFolder/test4txt' = false
[pred] preferpartial 'syncFolder/test4txt' = false
local nas
new file ----> syncFolder/Software_Config/Linux/variety/Downloaded/Desktoppr/02126_snowytracks_2560x1600.jpg
new file ----> syncFolder/Software_Config/Linux/variety/Downloaded/Unsplash/photo-1535941863447-76a4dc94e2ba.jpg
changed ----> syncFolder/Software_Config/Qnap/3_Unison/syncnas.sh
new file ----> syncFolder/test2.txt
new file ----> syncFolder/test4txt
Proceed with propagating updates? []
Broken
In the second case, with unisonresult=$( { unison $unisonparameters -debug verbose local; } ) the script (i.e., the unison command) does not show the prompt:
(...)
[server: update+] Unchanged file
[server: fileinfo+] /share/HDA_DATA/elrudi/syncFolder: true 1540240561.000000 1540240561.000000
[server: update] Setting archive for //nas//share/HDA_DATA/elrudi
[server: remote+] Sending result (id: 9)
[server: remote+] send [find-res] '\132\149\166\190\000\000\000/\000\000...' 67 bytes
[server: remote+] send [rsp] '\132\149\166\190\000\000\000\001\000\000...' 21 bytes
[remote_emit+] grab: \t\000\000\000b\024\000\000\000\233rsp\132\149\166\190\000\000\000\001\000\000\000\000\000\000\000\000\000\000\000\000#K\000\000\000\181find-res\132\149\166\190\000\000\000/\000\000\000\000\000\000\000 \000\000\000\029\160\176'syncFolder#\160\224\160\001\001\255\001\003\255##\145\012\000\000\128 \223\214A#\018_j\000\000\000\000\000\000\000\000\000##
[remote+] Message received (id: 9)
[server: remote_emit+] dump: \t\000\000\000b\024\000\000\000\233rsp\132\149\166\190\000\000\000\001\000\000\000\000\000\000\000\000\000\000\000\000#K\000\000\000\181find-res\132\149\166\190\000\000\000/\000\000\000\000\000\000\000 \000\000\000\029\160\176'syncFolder#\160\224\160\001\001\255\001\003\255##\145\012\000\000\128 \223\214A#\018_j\000\000\000\000\000\000\000\000\000##
[remote+] receive 'rsp\132\149\166\190\000\000\000...' 24 bytes
[remote+] receive 'find-res\132\149...' 75 bytes
[remote+] Waiting for next message
Reconciling changes
[recon] reconcileAll
[recon] reconcile: 3 results
[update] Marking 0 paths equal
[pred] sortlast 'syncFolder/Software_Config/Linux/variety/Downloaded/Unsplash/photo-1535941863447-76a4dc94e2ba.jpg' = false
[pred] sortlast 'syncFolder/test.txt' = false
[pred] sortfirst 'syncFolder/Software_Config/Linux/variety/Downloaded/Unsplash/photo-1535941863447-76a4dc94e2ba.jpg' = false
[pred] sortfirst 'syncFolder/test.txt' = false
[sort] syncFolder/Software_Config/Linux/variety/Downloaded/Unsplash/photo-1535941863447-76a4dc94e2ba.jpg <= syncFolder/test.txt --> -1
[pred] sortlast 'syncFolder/test.txt' = false
[pred] sortlast 'syncFolder/test2.txt' = false
[pred] sortfirst 'syncFolder/test.txt' = false
[pred] sortfirst 'syncFolder/test2.txt' = false
[sort] syncFolder/test.txt <= syncFolder/test2.txt --> -1
[pred] forcepartial 'syncFolder/Software_Config/Linux/variety/Downloaded/Unsplash/photo-1535941863447-76a4dc94e2ba.jpg' = false
[pred] preferpartial 'syncFolder/Software_Config/Linux/variety/Downloaded/Unsplash/photo-1535941863447-76a4dc94e2ba.jpg' = false
[pred] forcepartial 'syncFolder/test.txt' = false
[pred] preferpartial 'syncFolder/test.txt' = false
[pred] forcepartial 'syncFolder/test2.txt' = false
[pred] preferpartial 'syncFolder/test2.txt' = false
(hangs on last line)
Hope that helps!
I am using casperjs/phantomjs with this code
casper.test.begin('assertEquals() tests', 3, function(test) {
test.assertEquals(1 + 1, 3);
test.assertEquals([1, 2, 3], [1]);
test.assertEquals({a: 1, b: 2}, {a: 1, b: 4});
test.done();
});
In the console I get Failed tests as expected but what I can't understand is why the test suite is marked as PASS
PASS assertEquals() tests (3 tests)
FAIL 1 test executed in 0.029s, 0 passed, 1 failed, 0 dubious, 0 skipped.
I didn't regonized that before like this, but you also get the Error-Messages of the failing (first) equal.
The last PASS is just saying that casperjs is finished with the testsuite, no matter what is failing inside the suite.
This is the full log:
root#4332425a143d:/casperjs# casperjs test test.js
Test file: test.js
# assertEquals() tests
FAIL Subject equals the expected value
# type: assertEquals
# file: test.js
# subject: 2
# expected: 3
PASS assertEquals() tests (3 tests)
FAIL 1 test executed in 0.025s, 0 passed, 1 failed, 0 dubious, 0 skipped.
So that says that the first equals fails and the suite "assertEquals()" finished.
i am using Kibana 4 and my document contains two integer fields called: 'x' & 'y'. i would like to create a scripted field in Kibana returning the division value of 'x' by 'y' if 'y'<> 0. else: return the value of 'x'.
i have tried to add this script to a new screnter code hereipted field:
doc['x'].value > 0 ? doc['x'].value/doc['y'].value : doc['x'].value;
but got a parsing error when trying to visualize it:
Error: Request to Elasticsearch failed:
{"error":"SearchPhaseExecutionException[Failed to execute phase [query],
all shards failed; shardFailures
how can i create a scripted field with condition in Kibana, step by step?
What you are seeing is not a parsing error, shardFailures just means that the underlying Elasticsearch is not ready yet. When starting Kibana/Elasticsearch, make sure your ES cluster is ready before diving into Kibana, i.e. run curl -XGET localhost:9200/_cluster/health and in the response, you should see something similar to this:
{
cluster_name: your_cluster_name
status: yellow <----- this must be either yellow or green
timed_out: false
number_of_nodes: 2
number_of_data_nodes: 2
active_primary_shards: 227
active_shards: 454
relocating_shards: 0 <----- this must be 0
initializing_shards: 0 <----- this must be 0
unassigned_shards: 25
}
As for your script, it is written correctly, however the condition you mentioned is not correct since you wanted y <> 0 and not x > 0, so it should be
doc['y'].value != 0 ? doc['x'].value / doc['y'].value : doc['x'].value
Please give it a try