I have created a method that is called for each web element accessed by the scripts, as to avoid the "StaleElementReferenceError" thrown by selenium. This is how the code looks:
def reach_element(page,element)
begin
element.wait_until_present
rescue Selenium::WebDriver::Error::StaleElementReferenceError
puts '* retrying to reach element'
page.refresh
retry
end
end
It appears that the StaleElementReferenceError is ignored and the tests keep failing with this error.
Am I doing something wrong?
CORRECTIONS:
This error shouldn't appear at all for it to be rescued by ruby.
The main cause was the old version of watir-webdriver gem. If you still encounter this error, a simple gem update should do the trick.
We mostly got rid of stale element issues for when you take an action on an element in watir-webdriver last year. This is the code: https://github.com/watir/watir-webdriver/blob/master/lib/watir-webdriver/elements/element.rb#L597
When an action is taken on the element, but it is stale, it will re-look it up with the selector provided. It will fail for not existing if it isn't there.
Are you seeing your element go stale between when you locate it, but before it becomes visible? That's an interesting use case that I have plans to fix. If that is your issue, refreshing the page will force the element to go stale, so that will just repeat your issue. Remove the refresh, and it should keep relocating the stale element until it is present.
If that isn't the issue or that doesn't work, provide a stack trace of what you are seeing.
Related
This has been stumping me: Rails is throwing this error, after it's finished rendering my views, but before it gets back to the browser:
ActionView::Template::Error (undefined method `start_with?' for #<Proc:0x00005651bfe017f0>)
And... that's it. There's no stack trace. I get shown the standard 500 "We're sorry, but something went wrong" page, despite having config.consider_all_requests_local = true set. There are no further details either in the terminal or in log/development.log.
I can't find any Procs that it might be complaining about, nor can I find any calls to start_with? that might be the cause; I've gone back through Git history and isolated the issue to one commit (this one, if you want to take a look in detail), but nothing within that commit jumps out as being obvious.
Calling a render layout: false does work, as does simplifying my layouts/application.js down to just a <%= yield %>, which makes me think it might be something in there, however - I made no changes to it or any views at all in the commit in which the issue appeared.
What I'd really like to know is how I can get Rails to give me the stack trace for this error, so I can figure out where it's coming from. If you have any ideas where the bug itself might be, those are more than welcome too.
Drop this in an initializer (proc.rb):
class Proc
def start_with?(*args)
puts caller
end
end
I am getting the following error in a production rails application intermittently
NoMethodError (undefined method `values' on priority:Symbol.):
app/controllers/things_controller.rb:33:in `index'
The offending line looks like this:
#things = Thing.where(:some_column => 'some_value').order(:priority).reverse
Thing is an activerecord model.
The weird thing is, when I restart the application the error disappears. It is only under some strange set of circumstances that this happens (which I can't reproduce in preprod/dev environments).
Has anyone come across something like this before? Can anyone suggest how I would go about diagnosing this bug? The line in question doesn't seem to be the problem (the logs in production also don't show the full stacktrace)
After a length hair pulling session, I discovered that this is due to a bug in rubinius (2.2.10, and 2.2.9). The ActiveRecord query methods where and order both call enumerable#grep internally. After the application has been running for some time, or some unknown conditions are met, this function stops behaving correctly when the array contains symbols.
When a block is given as an argument to the grep function, this block will always be applied to the symbol elements of the array, regardless of the pattern given.
Bug report is here
I just launched a completely rebuilt in rails website and am using New Relic for error monitoring. I've been getting a lot of errors and alerts for what I'm guessing is people using bookmarks for pages/paths that no longer exist and possibly some hot linking.
What is the best way to resolve this situation so that I stop getting the alerts?
How about ignoring those errors?
ignore_errors - A comma separated list of Exception classes which will
be ignored
In addition, the error collector can be customized programmatically
for more control over filtering. In your application initialization,
you can register a block with the Agent to be called when an error is
detected. The block should return the error to record, or nil if the
error is to be ignored. For example:
config.after_initialize do
::NewRelic::Agent.ignore_error_filter do |error|
if error.message =~ /gateway down/
nil
elsif
error.class.name == "InvalidLicenseException"
StandardError.new "We should never see this..."
else
error
end
end
end
(source)
I generated a rails 3.2 migration with an empty down function, because the migration is irreversible (and I don't want to throw an exception). I run the migration successfully, but it has no effect. When I rollback, and run db:migrate again, the effects does apply.
I solved this easily by filling the empty down function with a code which does nothing, but it's still pretty ugly.
Does anyone knows why this happens? Is this a rails bug?
The exception is throwed to prevent destroying your database, if its irreversable, then that's probably the right thing to do.
Your #down could look like this:
def down
raise ActiveRecord::IrreversibleMigration, "Explain why its irreversable!"
end
That will save others a lot of headache as it clearly notifies about irreversable migration and explains the reason behind it :)
EDIT: I cannot confirm this behaviour for Rails 3.2.3. I've created several different migrations without #down, and no exceptino was raised. Maybe it's something in your code, which you didn't show a bit.
EDIT 2: Just to recap, when you're using up/down method, its your responsibility to raise ActiveRecord::IrreversibleMigration. In other case, nothing will happen (#down defined in AR will just return nil). The behaviour is different when you use #change. In some cases the mentioned exception can be raised by #inverse defined here: https://github.com/rails/rails/blob/565bfb9cd49285ebaa170141b4996c22ba81de43/activerecord/lib/active_record/migration/command_recorder.rb#L39 which is expected behaviour.
This is a repost on another issue, better isolated this time.
In my environment.rb file I changed this line:
config.time_zone = 'UTC'
to this line:
config.active_record.default_timezone = :utc
Ever since, this call:
Category.find(1).subcategories.map(&:id)
Fails on "Stack level too deep" error after the second time it is run in the development environment when config.cache_classes = false. If config.cache_classes = true, the problem does not occur.
The error is a result of the following code in active_record/attribute_methods.rb around line 252:
def method_missing(method_id, *args, &block)
...
if self.class.primary_key.to_s == method_name
id
....
The call to the "id" function re-calls method_missing and there is nothing that prevents the id to be called over and over again, resulting in stack level too deep.
I'm using Rails 2.3.8.
The Category model has_many :subcategories.
The call fails on variants of that line above (e.g. Category.first.subcategory_ids, use of "each" instead of "map", etc.).
Any thoughts will be highly appreciated.
Thanks!
Amit
Even though this is solved, I just wanted to chime in on this, and report how I fixed this issue. I had the same symptoms as the OP, initial request .id() worked fine, subsequent requests .id() would throw an the "stack too deep" error message. It's a weird error, as it generally it means you have an infinite loop somewhere. I fixed this by changing:
config.action_controller.perform_caching = true
config.cache_classes = false
to
config.action_controller.perform_caching = true
config.cache_classes = true
in environments/production.rb.
UPDATE: The root cause of this issue turned out to be the cache_store. The default MemoryStore will not preserve ActiveRecord models. This is a pretty old bug, and fairly severe, I'm not sure why it hasn't been fixed. Anyways, the workaround is to use a different cache_store. Try using this, in your config/environments/development.rb:
config.cache_store = :file_store
UPDATE #2: C. Bedard posted this analysis of the issue. Seems to sum it up nicely.
Having encountered this problem myself (and being stuck on it repeateadly) I have investigated the error (and hopefully found a good fix). Here's what I know about it:
It happens when ActiveRecord::Base#reset_subclasses is called by the dispatcher between requests (in dev mode only).
ActiveRecord::Base#reset_subclasses wipes out the inheritable_attributes Hash (where #skip_time_zone_conversion_for_attributes is stored).
It will not only happen on objects persisted through requests, as the "monkey test app" from #1290 shows, but also when trying to access generated association methods on AR, even for objects that live only on the current request.
This bug was introduced by this commit where the #skip_time_zone_conversion_for_attributes declaration was changed from base.cattr_accessor to base.class_inheritable_accessor. But then again, that same commit also fixed something else.
The patch initially submitted here that simply avoids clearing the instance_variables and instance_methods in reset_subclasses does introduce massive leaking, and the amounts leaked seem directly proportional to complexity of the app (i.e. number of models, associations and attributes on each of them). I have a pretty complex app which leaks nearly 1Mb on each request in dev mode when the patch is applied. So it's not viable (for me anyways).
While trying out different ways to solve this, I have corrected the initial error (skip_time_zone_conversion_for_attributes being nil on 2nd request), but it uncovered another error (which just didn't happen because the first exception would be raised before getting to it). That error seems to be the one reported in #774 (Stack overflow in method_missing for the 'id' method).
Now, for the solution, my patch (attached) does the following:
It adds wrapper methods for #skip_time_zone_conversion_for_attributes methods, making sure it always reads/writes the value as an class_inheritable_attribute. This way, nil is never returned anymore.
It ensures that the 'id' method is not wiped out when reset_subclasses is called. AR is kinda strange on that one, because it first defines it directly in the source, but redefines itself with #define_read_method when it is first called. And that is precisely what makes it fail after reloading (since reset_subclasses then wipes it out).
I also added a test in reload_models_test.rb, which calls reset_subclasses to try and simulate reloading between requests in dev mode. What I cannot tell at this point is if it really triggers the reloading mechanism as it does on a live dispatcher request cycle. I also tested from script/server and the error was gone.
Sorry for the long paste, it sucks that the rails lighthouse project is private. The patch mentioned above is private.
-- This answer is copied from my original post here.
Finally solved!
After posting a third question and with help of trptcolin, I could confirm a working solution.
The problem: I was using require to include models from within Table-less models (classes that are in app/models but do not extend ActiveRecord::Base). For example, I had a class FilterCategory that performed require 'category'. This messed up with Rails' class caching.
I had to use require in the first place since lines such as Category.find :all failed.
The solution (credit goes to trptcolin): replace Category.find :all with ::Category.find :all. This works without the need to explicitly require any model, and therefore doesn't cause any class caching problems.
The "stack too deep" problem also goes away when using config.active_record.default_timezone = :utc