I'm just get a Exception while running a Cucumber test and I tried to find what I can do for it, but no luck about that.
When I made a post in the last step:
When('accept terms of use') do
until #o == 200
#o = CadastroApp.sign_term1.code
sleep 1
end
end
class CadastroApp
include HTTParty
def self.sign_term1
post("#{$uat_uri}agree/multipleterms",
body: {
'ContractsId': $contract1,
'deviceType': 'Smartphone',
'Platform': 'ios',
'Model': 'Iphone XS max',
}.to_json,
headers: {
'Authorization': "Bearer #{$auth_token}",
'Content-Type': 'application/json'
})
end
end
I got the error:
52: def self.cucumber_run_with_backtrace_filtering(pseudo_method)
53: begin
54: yield
55: rescue Exception => e
56: instance_exec_invocation_line = "#{__FILE__}:#{__LINE__ - 2}:in `cucumber_run_with_backtrace_filtering'"
57: replace_instance_exec_invocation_line!((e.backtrace || []), instance_exec_invocation_line, pseudo_method)
58: raise e
59: end
60: end
I don't know if it is a problem, but I was using a lot of "until #variable == 200" to loop the api until I got response code 200.
It was a MYSQL problem. When I request the API, MYSQL don't close the requisition, so I get a lot of timeouts when I check on Kubernetes.
Exception Caught by LogRequestResponseMiddleware:
1) ----- Exception Type
MySql.Data.MySqlClient.MySqlException
1) ----- Exception Source
MySql.Data
1) ----- Exception TargetSite
MySql.Data.MySqlClient.Driver GetConnection()
1) ----- Exception Message
error connecting: Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached.
Message = error connecting: Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reac
hed.
So I republished the API and automation works fine.
This isn't a error. This is a response send by Ruby when I get a failure in the step.
Related
This is first time i am touching ruby, so no sure about correct terminology. I have tried searching for mulitple things, but couldn't find a solution.
I have this code block
domain_response = MyDomain::Api::MyApi::Api.new(parameters: message.to_domain_object, timeout: 1000)
# :nocov:
case (response = domain_response.response)
when MyDomain::Api::MyApi::SuccessResponse
## do something
when Domain::ErrorResponses::TimeoutResponse
## do something.
now i am trying to testing TimeoutResponse, I have written(tried) this
it "when api call timesout" do
expect(MyDomain::Api::MyApi::Api).to{
receive(:new)
} raise_error(MyDomain::ErrorResponses::TimeoutResponse)
end
this gave me error that unexpected identifier.
I have also tried by not providing receive, and it gave me error that block is expected.
Whats the proper way to raise an error that i can test?
Update:
Here is where i am stuck now
it "when api call timesout" do
# 1
expect(MyDomain::Api::MyApi::Api).to(
receive(:new),
).and_return(domain_api_instance)
# 2
expect(domain_api_instance.response).to receive(:response).and_raise(Domain::ErrorResponses::TimeoutResponse)
expect(domain_api_instance.response).to eq(ApiError::Timeout)
end
But with this code i am getting this error
1) Rpc::Package::SubPackage::V1::PackageService#first_test testing when api call timesout
Failure/Error: expect(domain_api_instance.response).to receive(:response).and_raise(Domain::ErrorResponses::TimeoutResponse)
#<InstanceDouble(MyDomain::Api::MyApi::Api) (anonymous)> received unexpected message :response with (no args)
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 an AWS Lambda which is designed for direct invocation from multiple applications within my team's service landscape. I'm writing a wrapper class which will perform this invocation, and associated validation and error detection / handling in the Lambda's response.
By design, the Lambda terminates with an unhandled exception if runtime validation of the invocation parameters fails. But I didn't expect to find that in spite of an unhandled function error, the status_code of the invocation response is 200:
[1] pry(main)> lambda_client = Aws::Lambda::Client.new(region: 'us-east-1')
=> #<Aws::Lambda::Client>
[2] pry(main)> invocation_response = lambda_client.invoke(function_name: 'jwt-tokens-dev-AccessTokenCreator')
=> #<struct Aws::Lambda::Types::InvocationResponse
status_code=200,
function_error="Unhandled",
log_result=nil,
payload=#<StringIO:0x007f91c1749028>,
executed_version="$LATEST">
[3] pry(main)> invocation_response.payload.string
=> "{\"errorMessage\": \"Required parameters are missing: role, sub, sub_type\", \"errorType\": \"ParamMissingError\", \"stackTrace\": [[\"/var/task/handler.py\", 15, \"access_token_creator\", \"return access_token_creator_handler(event, context)\"], [\"/var/task/access_token_creator.py\", 32, \"handler\", \"params = _validate_event_params(event)\"], [\"/var/task/access_token_creator.py\", 97, \"_validate_event_params\", \"raise ParamMissingError('Required parameters are missing: %s' % ', '.join(missing_params))\"]]}"
[4] pry(main)> ActiveSupport::JSON.decode(invocation_response.payload.string)
=> {"errorMessage"=>"Required parameters are missing: role, sub, sub_type",
"errorType"=>"ParamMissingError",
"stackTrace"=>
[["/var/task/handler.py", 15, "access_token_creator", "return access_token_creator_handler(event, context)"],
["/var/task/access_token_creator.py", 32, "handler", "params = _validate_event_params(event)"],
["/var/task/access_token_creator.py",
97,
"_validate_event_params",
"raise ParamMissingError('Required parameters are missing: %s' % ', '.join(missing_params))"]]}
Is it expected that the status code of the response of a direct Lambda invocation would be 200, despite an unhandled function error? I want to implement proper error response detection in my wrapper class, and searching for the key "errorType" in the top-level of the JSON response doesn't really seem so robust.
The solution -- too obvious, but not enough to distract from the "200" status_code -- is to check if function_error is nil.
The value is nil in the event of successful invocation:
[8] pry(main)> invocation_response = lambda_client.invoke(function_name: 'jwt-tokens-dev-AccessTokenCreator', payload: ActiveSupport::JSON::encode(sub:3285397, sub_type:'user', role:'admin'))
=> #<struct Aws::Lambda::Types::InvocationResponse
status_code=200,
function_error=nil,
log_result=nil,
payload=#<StringIO:0x007f91c2a2eeb8>,
executed_version="$LATEST">
Otherwise it has the value 'Unhandled' or 'Handled':
function_error ⇒ String
Indicates whether an error occurred while executing the Lambda function. If an error occurred this field will
have one of two values; Handled or Unhandled. Handled errors are
errors that are reported by the function while the Unhandled errors
are those detected and reported by AWS Lambda. Unhandled errors
include out of memory errors and function timeouts. For information
about how to report an Handled error, see Programming Model.
https://docs.aws.amazon.com/sdkforruby/api/Aws/Lambda/Types/InvocationResponse.html#function_error-instance_method
I came across the Timeout module in Ruby, and wanted to test it out. I looked at their official source code at http://ruby-doc.org/stdlib-2.1.1/libdoc/timeout/rdoc/Timeout.html
Here is the code I had
require 'timeout'
require 'benchmark'
numbers = [*1..80]
Timeout::timeout(5) { numbers.combination(5).count }
=> 24040016
I did some benchmarking tests, and got the following.
10.828000 0.063000 10.891000 11.001676
According to the documentation, this method is supposed to return an exception if the block is not executed within 5 seconds. If it is executed within the time frame, it will return the result of the code block
For what it's worth, I've tried timeout with 1 second, instead of 5 seconds, and I still get returned the result of the code block.
Here is the official documentation
timeout(sec, klass=nil)
Performs an operation in a block, raising an error if it takes longer than sec seconds to complete.
sec: Number of seconds to wait for the block to terminate. Any number may be used,
including Floats to specify fractional seconds. A value of 0 or nil will execute the
block without any timeout.
klass: Exception Class to raise if the block fails to terminate in sec seconds. Omitting
will use the default, Timeout::Error
I am mystified as to why this doesn't work.
The problem is the way MRI (Matz's Ruby Implementation) thread scheduling works. MRI uses a GIL (Global Interpreter Lock), which in practice means only one thread is truly running at a time.
There are some exception, but for the majority of the time there is only one thread executing Ruby code at any one time.
Normally you do not notice this, even during heavy computations that consume 100% CPU, because the MRI keeps time-slicing the threads at regular intervals so that each thread gets a turn to run.
However there's one exception where time-slicing isn't active and that's when a Ruby thread is executing native C-code instead of Ruby code.
Now it so happens that Array#combination is implemented in pure C:
[1] pry(main)> show-source Array#combination
From: array.c (C Method):
static VALUE
rb_ary_combination(VALUE ary, VALUE num)
{
...
}
When we combine this knowledge with how Timeout.timeout is implemented we can start to get a clue of what is happening:
[7] pry(main)> show-source Timeout#timeout
From: /opt/ruby21/lib/ruby/2.1.0/timeout.rb # line 75:
75: def timeout(sec, klass = nil) #:yield: +sec+
76: return yield(sec) if sec == nil or sec.zero?
77: message = "execution expired"
78: e = Error
79: bl = proc do |exception|
80: begin
81: x = Thread.current
82: y = Thread.start {
83: begin
84: sleep sec
85: rescue => e
86: x.raise e
87: else
88: x.raise exception, message
89: end
90: }
91: return yield(sec)
92: ensure
93: if y
94: y.kill
95: y.join # make sure y is dead.
96: end
97: end
98: end
99: ...
1xx: end
Your code running Array.combination most likely actually starts executing even BEFORE the timeout thread runs sleep sec on line 84. Your code is launched on line 91 through yield(sec).
This means the order of execution actually becomes:
1: [thread 1] numbers.combination(5).count
# ...some time passes while the combinations are calculated ...
2: [thread 2] sleep 5 # <- The timeout thread starts running sleep
3: [thread 1] y.kill # <- The timeout thread is instantly killed
# and never times out.
In order to make sure the timeout thread starts first you can try this, which will most likely trigger the timeout exception this time:
Timeout::timeout(5) { Thread.pass; numbers.combination(5).count }
This is because by running Thread.pass you allow the MRI scheduler to start and run the code on line 82 before the native combination C-code executes. However even in this case the exception won't be triggered until combination exits because of the GIL.
There is no way around this unfortunately. You would have to use something like JRuby instead, which has real concurrent threads. Or you could run the combination calculation in a Process instead of a thread.
I have a lot of errors of timeout in Mongoid. The error says that it's taking place in connectable.rb#16. I found the source of this https://github.com/mongoid/moped/blob/master/lib/moped/sockets/connectable.rb#L16
or here as well
https://github.com/mongoid/moped/blob/master/lib/moped/sockets/connectable.rb#L45
https://github.com/mongoid/moped/blob/master/lib/moped/sockets/connectable.rb#L60
So what do I have to do with that error, how do I raise the timeout to get rid of the error?
P.S. It's a sinatra app, here is the stack trace of one of them.
Timeout::Error at /
execution expired
file: connectable.rb location: write line: 60
/var/lib/gems/1.9.1/gems/moped-1.3.2/lib/moped/sockets/connectable.rb 60 in write
handle_socket_errors { super }
/var/lib/gems/1.9.1/gems/moped-1.3.2/lib/moped/sockets/connectable.rb 60 in block in write
handle_socket_errors { super }
/var/lib/gems/1.9.1/gems/moped-1.3.2/lib/moped/sockets/connectable.rb 78 in handle_socket_errors
yield
/var/lib/gems/1.9.1/gems/moped-1.3.2/lib/moped/sockets/connectable.rb 60 in write
handle_socket_errors { super }
/var/lib/gems/1.9.1/gems/moped-1.3.2/lib/moped/connection.rb 156 in block in write
socket.write(buf)
/var/lib/gems/1.9.1/gems/moped-1.3.2/lib/moped/connection.rb 202 in with_connection
yield #sock