undefined method `state=' for nil:NilClass since 0.3.1

Yesterday we've upgraded rack-timeout to 0.3.1 from 0.2.4 and we started seeing this error on production (we're using heroku) :

    [GEM_ROOT]/gems/rack-timeout-0.3.1/lib/rack/timeout/core.rb:168 :in `_set_state!`

    166     def self._set_state!(env, state)
    167       raise "Invalid state: #{state.inspect}" unless VALID_STATES.include? state
    168       env[ENV_INFO_KEY].state = state
    169       notify_state_change_observers(env)
    170     end

    [GEM_ROOT]/gems/rack-timeout-0.3.1/lib/rack/timeout/core.rb:115 :in `block in call`
    [GEM_ROOT]/gems/rack-timeout-0.3.1/lib/rack/timeout/core.rb:117 :in `call`
    [GEM_ROOT]/gems/rack-timeout-0.3.1/lib/rack/timeout/core.rb:117 :in `block in call`
    [GEM_ROOT]/gems/rack-timeout-0.3.1/lib/rack/timeout/support/scheduler.rb:39 :in `call`
    [GEM_ROOT]/gems/rack-timeout-0.3.1/lib/rack/timeout/support/scheduler.rb:39 :in `run!`
    [GEM_ROOT]/gems/rack-timeout-0.3.1/lib/rack/timeout/support/scheduler.rb:52 :in `run!`
    [GEM_ROOT]/gems/rack-timeout-0.3.1/lib/rack/timeout/support/scheduler.rb:99 :in `block (2 levels) in run_loop!`
    [GEM_ROOT]/gems/rack-timeout-0.3.1/lib/rack/timeout/support/scheduler.rb:99 :in `each`
    [GEM_ROOT]/gems/rack-timeout-0.3.1/lib/rack/timeout/support/scheduler.rb:99 :in `block in run_loop!`
    [GEM_ROOT]/gems/rack-timeout-0.3.1/lib/rack/timeout/support/scheduler.rb:80 :in `loop`
    [GEM_ROOT]/gems/rack-timeout-0.3.1/lib/rack/timeout/support/scheduler.rb:80 :in `run_loop!`
    [GEM_ROOT]/gems/rack-timeout-0.3.1/lib/rack/timeout/support/scheduler.rb:72 :in `block (2 levels) in runner`

Rack middlewares on production:
use Honeybadger::Rack::UserInformer
use Honeybadger::Rack::UserFeedback
use Honeybadger::Rack::ErrorNotifier
use HireFire::Middleware
use Rack::Cors
use Rack::UTF8Sanitizer
use Rack::Sendfile
use ActionDispatch::Static
use #<ActiveSupport::Cache::Strategy::LocalCache::Middleware:0x007f7d7d3117b0>
use Rack::Timeout
use Rack::Runtime
use Rack::MethodOverride
use ActionDispatch::RequestId
use Rails::Rack::Logger
use ActionDispatch::ShowExceptions
use ActionDispatch::DebugExceptions
use ActionDispatch::RemoteIp
use ActionDispatch::Callbacks
use ActionDispatch::Cookies
use ActionDispatch::Session::CookieStore
use ActionDispatch::Flash
use ActionDispatch::ParamsParser
use Rack::Head
use Rack::ConditionalGet
use Rack::ETag
use Warden::Manager
use JQuery::FileUpload::Rails::Middleware

Tried reproducing locally but I can't seem to find the right conditions to do so.

How frequently/consistently are you seeing this in production? Is it for all request? A particular set of? A seemingly random set?
Do you have the full logs for a failing request? I wanna see what rack-timeout logs before the failure.
Looking at the code in https://github.com/heroku/rack-timeout/blob/v0.3.2/lib/rack/timeout/core.rb you can see the value is init'd in L81, and _set_state! seems to get successfully called in L109… So I suspect something else during the request to be affecting env and for some reason clearing out rack-timeout's info struct. (and maybe more?)
register_state_change is called repeatedly in a separate thread, but I suspect the main thread would already be doing L125.

How frequently/consistently are you seeing this in production?

About 300 times for a 15h period.

Is it for all requests?

Some. For other we do get standard RequestTimeout exceptions.

A particular set of?

Seemingly random. But for endponts that don't usually (or at all) timeout

Do you have the full logs for a failing request?

No, unfortunately.
So the Rack::Timeout middleware order changed grabbed my attention from the change log. And we deployed a rendom fix that moved Rack::Timeout before Rack::Cors in the middleware list. And for the past 10h we haven't had a single error.
I'm closing this. I don't currently have logs or any more debug information, and we no longer see the issue.

Yeah I was wondering if the middleware order was to blame. Can you paste here the new middleware list? Probably one of them is doing something funny.

Ok, I spoke too soon :)
We encountered the same issue eventually. I insta-reverted to 0.2.4 once I saw it.
It occurred exactly 2 times ~10min apart.
So, I really want to be able to provide some more debug info, but I'm still unable to reproduce locally. And we can't run 0.3.x on production for now. Anything I can do to provide more info?
I'don't know what's the policy for issues like this, I reopened it, but I understand if due to the lack of debug data you close it.

Well I'd like to get it fixed.
If I make a debug branch will you run it?
The idea, if the info struct is not present, is to give up on the timeout code but let the request finish normally, whilst along with it logging some debug info.

Yep, sure we can run that.

Ok, try with:
gem "rack-timeout", github:"heroku", branch:"vanishing-env-info-debug"

This will log some extra stuff that'll be helpful in understanding what's going on. Additionally it'll not raise if info is not present.
It's a lot of logging per request so just run it long enough to run into the issue a few times. Maybe half a day or so?
You'll need a log retention add-on with heroku.
Can you open a ticket with heroku support and ask that it be sent my way? Also make sure you grant application access so I can inspect your log retention add-on.

Hey, Thanks!
Just deployed to production and created the ticket with heroku. We've added papertrail for the logs hope the data size would be enough there.

Ok, this started appearing now:
TypeError: nil is not a symbol
GEM_ROOT]/bundler/gems/rack-timeout-60e99cb3108a/lib/rack/timeout/logging-observer.rb:42 :in `log_state_change`
40     info = env[::Rack::Timeout::ENV_INFO_KEY]
41     level = STATE_LOG_LEVEL[info.state]
42     logger(env).send(level) do
43       s  = "source=rack-timeout"
44       s << " id="      << info.id           if info.id
[GEM_ROOT]/bundler/gems/rack-timeout-60e99cb3108a/lib/rack/timeout/core.rb:199 :in `call`
[GEM_ROOT]/bundler/gems/rack-timeout-60e99cb3108a/lib/rack/timeout/core.rb:199 :in `block in notify_state_change_observers`
[GEM_ROOT]/bundler/gems/rack-timeout-60e99cb3108a/lib/rack/timeout/core.rb:199 :in `each`
[GEM_ROOT]/bundler/gems/rack-timeout-60e99cb3108a/lib/rack/timeout/core.rb:199 :in `notify_state_change_observers`
[GEM_ROOT]/bundler/gems/rack-timeout-60e99cb3108a/lib/rack/timeout/core.rb:176 :in `_set_state!`
[GEM_ROOT]/bundler/gems/rack-timeout-60e99cb3108a/lib/rack/timeout/core.rb:117 :in `block in call`
[GEM_ROOT]/bundler/gems/rack-timeout-60e99cb3108a/lib/rack/timeout/core.rb:119 :in `call`
[GEM_ROOT]/bundler/gems/rack-timeout-60e99cb3108a/lib/rack/timeout/core.rb:119 :in `block in call`
[GEM_ROOT]/bundler/gems/rack-timeout-60e99cb3108a/lib/rack/timeout/support/scheduler.rb:39 :in `call`
[GEM_ROOT]/bundler/gems/rack-timeout-60e99cb3108a/lib/rack/timeout/support/scheduler.rb:39 :in `run!`
[GEM_ROOT]/bundler/gems/rack-timeout-60e99cb3108a/lib/rack/timeout/support/scheduler.rb:52 :in `run!`
[GEM_ROOT]/bundler/gems/rack-timeout-60e99cb3108a/lib/rack/timeout/support/scheduler.rb:99 :in `block (2 levels) in run_loop!`
[GEM_ROOT]/bundler/gems/rack-timeout-60e99cb3108a/lib/rack/timeout/support/scheduler.rb:99 :in `each`
[GEM_ROOT]/bundler/gems/rack-timeout-60e99cb3108a/lib/rack/timeout/support/scheduler.rb:99 :in `block in run_loop!`
[GEM_ROOT]/bundler/gems/rack-timeout-60e99cb3108a/lib/rack/timeout/support/scheduler.rb:80 :in `loop`
[GEM_ROOT]/bundler/gems/rack-timeout-60e99cb3108a/lib/rack/timeout/support/scheduler.rb:80 :in `run_loop!`
[GEM_ROOT]/bundler/gems/rack-timeout-60e99cb3108a/lib/rack/timeout/support/scheduler.rb:72 :in `block (2 levels) in runner`

I made some updates to the branch and asked you on the heroku ticket to re-deploy but haven't heard from you since. Any news?

Yeah, quite simple: we hit our papertrail plan limit and I was gonna deploy the branch tomorrow on next  month's quota. I'll reopen the ticket when it's done.

We're seeing the same thing. Rolling back to an older version of rack-timeout.
We'll try running your branch on our staging environment to see if we can replicate the error.

What I gather from the logs so far is, when this happens, env has been basically cleared. There's a single key in it. Next commit I'll print the key so we know which.
Also, all the failing calls happen coming from the heartbeat_event proc, which runs in another thread. Also, the heartbeat is basically irrelevant to the main operation of rack timeout. It's only really used for logging purposes atm. So it's fine to just bail if info is not present.
But I wanna get to the bottom of this first.

Ok, about to push some updates. When you deploy with the new updates, can you set Rack::Timeout::Logger.level  = Logger::DEBUG or at least Logger::INFO?

New things are in. Please run in prod a couple days, accumulate some logs, and let me know so I can download them. You might get attention faster if you notify me in the support ticket.
@metade if you wanna do the same, you're welcome. This branch is safe to run in prod, it should not explode as it just skips stuff if env has been cleared.

I get the following error when I run this new debug branch, start the development server, and try to do a request.
=> Booting Thin
=> Rails 4.2.4 application starting in development on http://localhost:3000
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server
Thin web server (v1.6.4 codename Gob Bluth)
Maximum connections set to 1024
Listening on localhost:3000, CTRL+C to stop
/Users/nvloff/work/Textmaster.com/vendor/ruby/2.0.0/bundler/gems/rack-timeout-5e579ee5fe7b/lib/rack/timeout/core.rb:23: [BUG] object allocation during garbage collection phase
ruby 2.0.0p481 (2014-05-08) [x86_64-darwin14.1.0]

-- Crash Report log information --------------------------------------------
   See Crash Report log file under the one of following:
     * ~/Library/Logs/CrashReporter
     * /Library/Logs/CrashReporter
     * ~/Library/Logs/DiagnosticReports
     * /Library/Logs/DiagnosticReports
   the more detail of.

-- Control frame information -----------------------------------------------
c:1613 p:---- s:12029 e:002028 CFUNC  :caller
c:1612 p:0018 s:12025 e:002020 METHOD /Users/nvloff/work/Textmaster.com/vendor/ruby/2.0.0/bundler/gems/rack-timeout-5e579ee5fe7b/lib/rack/timeout/core.rb:23
c:1611 p:0013 s:12015 e:002014 LAMBDA /Users/nvloff/work/Textmaster.com/vendor/ruby/2.0.0/bundler/gems/rack-timeout-5e579ee5fe7b/lib/rack/timeout/core.rb:16 [FINISH]
c:1610 p:0021 s:12011 e:002005 METHOD /Users/nvloff/work/Textmaster.com/vendor/ruby/2.0.0/bundler/gems/rack-timeout-5e579ee5fe7b/lib/rack/timeout/core.rb:23
c:1609 p:0013 s:12000 e:001999 LAMBDA /Users/nvloff/work/Textmaster.com/vendor/ruby/2.0.0/bundler/gems/rack-timeout-5e579ee5fe7b/lib/rack/timeout/core.rb:16 [FINISH]
c:1608 p:0021 s:11996 e:001990 METHOD /Users/nvloff/work/Textmaster.com/vendor/ruby/2.0.0/bundler/gems/rack-timeout-5e579ee5fe7b/lib/rack/timeout/core.rb:23
c:1607 p:0013 s:11985 e:001984 LAMBDA /Users/nvloff/work/Textmaster.com/vendor/ruby/2.0.0/bundler/gems/rack-timeout-5e579ee5fe7b/lib/rack/timeout/core.rb:16 [FINISH]

... snip ..

/Users/nvloff/work/Textmaster.com/vendor/ruby/2.0.0/bundler/gems/rack-timeout-5e579ee5fe7b/lib/rack/timeout/core.rb:23:in `__log_method_call'
/Users/nvloff/work/Textmaster.com/vendor/ruby/2.0.0/bundler/gems/rack-timeout-5e579ee5fe7b/lib/rack/timeout/core.rb:16:in `block (2 levels) in extended'
/Users/nvloff/work/Textmaster.com/vendor/ruby/2.0.0/bundler/gems/rack-timeout-5e579ee5fe7b/lib/rack/timeout/core.rb:23:in `__log_method_call'
/Users/nvloff/work/Textmaster.com/vendor/ruby/2.0.0/bundler/gems/rack-timeout-5e579ee5fe7b/lib/rack/timeout/core.rb:16:in `block (2 levels) in extended'
/Users/nvloff/work/Textmaster.com/vendor/ruby/2.0.0/bundler/gems/rack-timeout-5e579ee5fe7b/lib/rack/timeout/core.rb:23:in `__log_method_call'
/Users/nvloff/work/Textmaster.com/vendor/ruby/2.0.0/bundler/gems/rack-timeout-5e579ee5fe7b/lib/rack/timeout/core.rb:23:in `caller'

-- C level backtrace information -------------------------------------------

Full error: https://gist.github.com/nvloff/ccb7ebfecfe5f2d8dd80

Ugh. Could you try with ruby 2.2.3?

@metade which ruby version are you on btw?

@kch not anytime soon. we'll be on 2.0 for a while. We have 2.2.3 under testing but we may decide against running it on prod. I'll know more next week.

OK, I'll see if I can figure out wth is going on with 2.0.0

Even for 2.0, there's a newer patchlevel ( 2.0.0-p647), you might want to at least look into that. Not sure if it would fix anything for this issue tho.

@nvloff so I tried here with same ruby, rails, and thin versions, and the error did not happen for my test app.

@nvloff you only tried that locally yes? I'd say try in new staging app on heroku?
I also pushed a new commit to the branch. There's a slight chance it may make things better.
(Also if you recently updated OS X, any chance something's off with your ruby after that?)

Hey, now I don't get that error, but just the dev server keeps on loading and never finishes a request. I now get this same behaviour even with the previous commit.
It's probably something local, I'll check my setup and get back to you. May take me a couple of days as I'm a bit swamped with other things right now.

Hi, we are getting the same error on our heroku deployed application.

NoMethodError: undefined method `state=' for nil:NilClass
…2.2.0/gems/rack-timeout-0.3.2/lib/rack/timeout/core.rb:  168:in `_set_state!'
…2.2.0/gems/rack-timeout-0.3.2/lib/rack/timeout/core.rb:  115:in `block in call'
…2.2.0/gems/rack-timeout-0.3.2/lib/rack/timeout/core.rb:  117:in `call'
…2.2.0/gems/rack-timeout-0.3.2/lib/rack/timeout/core.rb:  117:in `block in call'
…ck-timeout-0.3.2/lib/rack/timeout/support/scheduler.rb:   39:in `call'
…ck-timeout-0.3.2/lib/rack/timeout/support/scheduler.rb:   39:in `run!'
…ck-timeout-0.3.2/lib/rack/timeout/support/scheduler.rb:   52:in `run!'
…ck-timeout-0.3.2/lib/rack/timeout/support/scheduler.rb:   99:in `block (2 levels) in run_loop!'…ck-timeout-0.3.2/lib/rack/timeout/support/scheduler.rb:   99:in `each'
…ck-timeout-0.3.2/lib/rack/timeout/support/scheduler.rb:   99:in `block in run_loop!'
…ck-timeout-0.3.2/lib/rack/timeout/support/scheduler.rb:   80:in `loop'
…ck-timeout-0.3.2/lib/rack/timeout/support/scheduler.rb:   80:in `run_loop!'
…ck-timeout-0.3.2/lib/rack/timeout/support/scheduler.rb:   72:in `block (2 levels) in runner'

I used to get this as well https://github.com/heroku/rack-timeout/issues/57 and never was able to resolve.
I subscribed to this issue and am really interested in its conclusion :)

@kch
I am using Heroku as well and have changed the logger to logger::ERROR and have set the rack_timeout.rb to the following:-
Rack::Timeout::timeout = 120
Rack::Timeout::Logger.logger = Logger.new($stderr)
Rack::Timeout::Logger.level  = Logger::ERROR

The message still appears as below:-
Dec 16 11:31:15 xxxappname app/web.1:  E, [2015-12-16T03:31:15.661861 #9] ERROR -- : listen loop error: undefined method `state=' for nil:NilClass (NoMethodError)
Dec 16 11:31:15 xxxappname app/web.1:  E, [2015-12-16T03:31:15.661942 #9] ERROR -- : /app/vendor/bundle/ruby/2.2.0/gems/rack-timeout-0.3.2/lib/rack/timeout/core.rb:168:in `_set_state!'
Dec 16 11:31:15 xxxappname app/web.1:  E, [2015-12-16T03:31:15.661989 #9] ERROR -- : /app/vendor/bundle/ruby/2.2.0/gems/rack-timeout-0.3.2/lib/rack/timeout/core.rb:115:in `block in call'
Dec 16 11:31:15 xxxappname app/web.1:  E, [2015-12-16T03:31:15.662031 #9] ERROR -- : /app/vendor/bundle/ruby/2.2.0/gems/rack-timeout-0.3.2/lib/rack/timeout/core.rb:117:in `call'
Dec 16 11:31:15 xxxappname app/web.1:  E, [2015-12-16T03:31:15.662071 #9] ERROR -- : /app/vendor/bundle/ruby/2.2.0/gems/rack-timeout-0.3.2/lib/rack/timeout/core.rb:117:in `block in call'
Dec 16 11:31:15 xxxappname app/web.1:  E, [2015-12-16T03:31:15.662111 #9] ERROR -- : /app/vendor/bundle/ruby/2.2.0/gems/rack-timeout-0.3.2/lib/rack/timeout/support/scheduler.rb:39:in `call'
Dec 16 11:31:15 xxxappname app/web.1:  E, [2015-12-16T03:31:15.662150 #9] ERROR -- : /app/vendor/bundle/ruby/2.2.0/gems/rack-timeout-0.3.2/lib/rack/timeout/support/scheduler.rb:39:in `run!'
Dec 16 11:31:15 xxxappname app/web.1:  E, [2015-12-16T03:31:15.662190 #9] ERROR -- : /app/vendor/bundle/ruby/2.2.0/gems/rack-timeout-0.3.2/lib/rack/timeout/support/scheduler.rb:52:in `run!'
Dec 16 11:31:15 xxxappname app/web.1:  E, [2015-12-16T03:31:15.662229 #9] ERROR -- : /app/vendor/bundle/ruby/2.2.0/gems/rack-timeout-0.3.2/lib/rack/timeout/support/scheduler.rb:99:in `block (2 levels) in run_loop!'
Dec 16 11:31:15 xxxappname app/web.1:  E, [2015-12-16T03:31:15.662269 #9] ERROR -- : /app/vendor/bundle/ruby/2.2.0/gems/rack-timeout-0.3.2/lib/rack/timeout/support/scheduler.rb:99:in `each'
Dec 16 11:31:15 xxxappname app/web.1:  E, [2015-12-16T03:31:15.662308 #9] ERROR -- : /app/vendor/bundle/ruby/2.2.0/gems/rack-timeout-0.3.2/lib/rack/timeout/support/scheduler.rb:99:in `block in run_loop!'
Dec 16 11:31:15 xxxappname app/web.1:  E, [2015-12-16T03:31:15.662347 #9] ERROR -- : /app/vendor/bundle/ruby/2.2.0/gems/rack-timeout-0.3.2/lib/rack/timeout/support/scheduler.rb:80:in `loop'
Dec 16 11:31:16 xxxappname app/web.1:  E, [2015-12-16T03:31:15.662386 #9] ERROR -- : /app/vendor/bundle/ruby/2.2.0/gems/rack-timeout-0.3.2/lib/rack/timeout/support/scheduler.rb:80:in `run_loop!'
Dec 16 11:31:16 xxxappname app/web.1:  E, [2015-12-16T03:31:15.662426 #9] ERROR -- : /app/vendor/bundle/ruby/2.2.0/gems/rack-timeout-0.3.2/lib/rack/timeout/support/scheduler.rb:72:in `block (2 levels) in runner'

Please advise if there is anything else we can do to assist with more information to help resolve the issue.

migrating my comment over from the closed issue #57:
Seeing a similar issue on jruby 1.7.19 using puma 2.15.3 and rack-timeout 0.3.2.
NoMethodError: undefined method `state' for nil:NilClass
               log_state_change at /code/jruby/1.9/gems/rack-timeout-0.3.2/lib/rack/timeout/logging-observer.rb:41
                           call at org/jruby/RubyProc.java:271
  notify_state_change_observers at /code/jruby/1.9/gems/rack-timeout-0.3.2/lib/rack/timeout/core.rb:192
                           each at org/jruby/RubyArray.java:1613
  notify_state_change_observers at /code/jruby/1.9/gems/rack-timeout-0.3.2/lib/rack/timeout/core.rb:192
                    _set_state! at /code/jruby/1.9/gems/rack-timeout-0.3.2/lib/rack/timeout/core.rb:169
                           call at /code/jruby/1.9/gems/rack-timeout-0.3.2/lib/rack/timeout/core.rb:115
                           call at org/jruby/RubyProc.java:271
                           call at /code/jruby/1.9/gems/rack-timeout-0.3.2/lib/rack/timeout/core.rb:117
                           call at org/jruby/RubyProc.java:271
                           run! at /code/jruby/1.9/gems/rack-timeout-0.3.2/lib/rack/timeout/support/scheduler.rb:39
                           run! at /code/jruby/1.9/gems/rack-timeout-0.3.2/lib/rack/timeout/support/scheduler.rb:52
                      run_loop! at /code/jruby/1.9/gems/rack-timeout-0.3.2/lib/rack/timeout/support/scheduler.rb:99
                           each at org/jruby/RubyArray.java:1613
                      run_loop! at /code/jruby/1.9/gems/rack-timeout-0.3.2/lib/rack/timeout/support/scheduler.rb:99
                           loop at org/jruby/RubyKernel.java:1507
                      run_loop! at /code/jruby/1.9/gems/rack-timeout-0.3.2/lib/rack/timeout/support/scheduler.rb:80
                         runner at /code/jruby/1.9/gems/rack-timeout-0.3.2/lib/rack/timeout/support/scheduler.rb:72

It also appears to have resulted / coincided with a crash in the puma process. could be an out of memory issue?

+1 We are seeing this too pretty frequently on our app deployed to dedicated servers (not on heroku). We are running 2.2.3

@kch Any update here?

I would like to add that I'm actually seeing these undefined method errors on 0.2.4 (which was believed not to have the issue) not just on the latest release. Interestingly, they're not crashing the process in 0.2.4, but they appear to be crashing the thread.

Ok, I'm ready to get back to this.
So everyone willing to help, I still need data.
If you're willing, please run this branch, and if you're on heroku, add a log retention add-on. (otherwise, you know, keep your logs somehow.)
It'll log A LOT OF DATA. I'm trying to track down what is resetting the env, so if it's nil I'll log stack traces for all methods sent to env during that request.
When you have some of those, please paste them here. All lines interesting to me start with source=rack-timeout-debug.

Also keep in mind that this branch pretends everything is ok when our env info is nil and let's the request proceed as normal, just without enforcing timeout. Which is a nice benefit while we don't have a fix.

@kch Any chance you can make the branch into a rc release so we can test it and then revert if needed using the gemfile?

@DSAMPAT why can't you just gem "rack-timeout", github:"heroku", branch:"vanishing-env-info-debug" ?

Well, giving the wrong code wasn't very helpful. What I meant is, add this to your Gemfile:
gem "rack-timeout", github:"heroku/rack-timeout", branch:"vanishing-env-info-debug"

I'm hoping to get this fixed for the next release, but I can only do that if I see some debug data as I have so far not been able to reproduce this nor observed it in any of our systems.

@kch used the above code and got the error immediately after updating the app. View updated error log below. Hope it is of use and related to the same issue.
Mar 08 20:36:12 appname heroku/web.1:  Starting process with command `bundle exec unicorn -p 8082 -c ./config/unicorn.rb`
Mar 08 20:36:16 appname app/web.1:  I, [2016-03-09T04:36:16.251672 #3]  INFO -- : Refreshing Gem list
Mar 08 20:36:19 appname app/web.1:  I, [2016-03-09T04:36:18.854026 #3]  INFO -- : listening on addr=<IP_ADDRESS>:8082 fd=9
Mar 08 20:36:19 appname app/web.1:  I, [2016-03-09T04:36:18.893064 #6]  INFO -- : worker=0 ready
Mar 08 20:36:19 appname app/web.1:  I, [2016-03-09T04:36:18.893274 #3]  INFO -- : master process ready
Mar 08 20:36:19 appname app/web.1:  I, [2016-03-09T04:36:18.896350 #9]  INFO -- : worker=1 ready
Mar 08 20:36:19 appname app/web.1:  I, [2016-03-09T04:36:18.898024 #12]  INFO -- : worker=2 ready
Mar 08 20:36:19 appname heroku/web.1:  State changed from starting to up
Mar 08 20:36:21 appname heroku/router:  at=info method=GET path="/" host=appname.herokuapp.com request_id=1e5218fc-12e5-4ea6-bb4f-c81678d169eb fwd="xxx.xxx.xxx.xxx" dyno=web.1 connect=2ms service=5ms status=500 bytes=38
Mar 08 20:36:21 appname app/web.1:  source=rack-timeout id=1e5218fc-12e5-4ea6-bb4f-c81678d169eb wait=33172ms timeout=30000ms state=expired at=error
Mar 08 20:36:21 appname app/web.1:  E, [2016-03-09T04:36:21.559318 #12] ERROR -- : app error: Request older than 30000ms. (Rack::Timeout::RequestExpiryError)
Mar 08 20:36:21 appname app/web.1:  E, [2016-03-09T04:36:21.559404 #12] ERROR -- : /app/vendor/bundle/ruby/2.2.0/gems/rack-timeout-0.3.2/lib/rack/timeout/core.rb:98:in `call'
Mar 08 20:36:21 appname app/web.1:  E, [2016-03-09T04:36:21.559454 #12] ERROR -- : /app/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.3/lib/active_support/cache/strategy/local_cache_middleware.rb:28:in `call'
Mar 08 20:36:21 appname app/web.1:  E, [2016-03-09T04:36:21.559501 #12] ERROR -- : /app/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.3/lib/action_dispatch/middleware/static.rb:116:in `call'
Mar 08 20:36:21 appname app/web.1:  E, [2016-03-09T04:36:21.559542 #12] ERROR -- : /app/vendor/bundle/ruby/2.2.0/gems/rack-1.6.4/lib/rack/sendfile.rb:113:in `call'
Mar 08 20:36:21 appname app/web.1:  E, [2016-03-09T04:36:21.559606 #12] ERROR -- : /app/vendor/bundle/ruby/2.2.0/gems/railties-4.2.3/lib/rails/engine.rb:518:in `call'
Mar 08 20:36:21 appname app/web.1:  E, [2016-03-09T04:36:21.559640 #12] ERROR -- : /app/vendor/bundle/ruby/2.2.0/gems/railties-4.2.3/lib/rails/application.rb:165:in `call'
Mar 08 20:36:21 appname app/web.1:  E, [2016-03-09T04:36:21.559681 #12] ERROR -- : /app/vendor/bundle/ruby/2.2.0/gems/unicorn-4.9.0/lib/unicorn/http_server.rb:580:in `process_client'
Mar 08 20:36:21 appname app/web.1:  E, [2016-03-09T04:36:21.559718 #12] ERROR -- : /app/vendor/bundle/ruby/2.2.0/gems/unicorn-4.9.0/lib/unicorn/http_server.rb:674:in `worker_loop'
Mar 08 20:36:21 appname app/web.1:  E, [2016-03-09T04:36:21.559765 #12] ERROR -- : /app/vendor/bundle/ruby/2.2.0/gems/unicorn-4.9.0/lib/unicorn/http_server.rb:529:in `spawn_missing_workers'
Mar 08 20:36:21 appname app/web.1:  E, [2016-03-09T04:36:21.559812 #12] ERROR -- : /app/vendor/bundle/ruby/2.2.0/gems/unicorn-4.9.0/lib/unicorn/http_server.rb:140:in `start'
Mar 08 20:36:21 appname app/web.1:  E, [2016-03-09T04:36:21.559850 #12] ERROR -- : /app/vendor/bundle/ruby/2.2.0/gems/unicorn-4.9.0/bin/unicorn:126:in `<top (required)>'
Mar 08 20:36:21 appname app/web.1:  E, [2016-03-09T04:36:21.559904 #12] ERROR -- : /app/vendor/bundle/ruby/2.2.0/bin/unicorn:23:in `load'
Mar 08 20:36:21 appname app/web.1:  E, [2016-03-09T04:36:21.559971 #12] ERROR -- : /app/vendor/bundle/ruby/2.2.0/bin/unicorn:23:in `<main>'

:+1: We are also have this issue and have no idea whats causing it. It seems almost random even though we are sure its not.

@DSAMPAT that seems just an artefact of having restarted the dyno. Some requests that had been waiting too long for the dyno to come back online will be deemed too old. Did the app run fine after that?

@mbasset you're welcome to try this debug branch too then :)

@kch I have implemented the code change on the Production code but pushed it to a Staging site. Yes, the app is running fine with the code. Now whenever it resumes from an idle state, the same few lines come up, other than that, the old errors have not appeared.
Maybe @mbasset can confirm that his errors have disappeared as well.

We tried the debug branch and got massive memory consumption. The application seemed to grow in memory size without bounds when using the debug branch. We have had to use a custom version of the gem where we essentially bypass the problem to avoid it translating into an end user 5xx error for now. Unfortunately not meaningful debug information could be retrieved when using the gem the first time as the server would go critical shortly after the code was used and become extremely unresponsive.

Should mention we are using ruby 2.2.4 with rails <IP_ADDRESS> and a whole lot of other gems.

@mbasset hum I do store a lot of stuff during the request in the debug branch, but it should all expire after that. I have an idea about how to do this without logging every damn access to env. I'll update the branch when I can. Hopefully soon.

@DSAMPAT yeah the branch bypasses the error, but it logs a bunch of stuff when it happens. I'm looking for log lines containing source=rack-timeout-debug. Can you search your logs for some?

@mbasset @DSAMPAT alright, I've updated the branch with new code. It should be a lot easier on your memory and logs. It'll only log the trace at the moment the rack-timeout key disappears from env.
We'll still be looking for log lines with source=rack-timeout-debug.

@kch Have you made the change on the actual release? The errors were occurring every 2 to 4 mins and stopped last night at around your last comment.

I made the changes in the branch. If you bundle updated it'd update the branch.

@DSAMPAT if you're seeing the errors then do you have the log lines that I need?

@kch The gem doesn't work after bundle update was done. It runs on my local machine, but does not work on Heroku. Can you do rc version? Then I can lock it in the gemfile to confirm that it is not any other gem causing the app to not compile. I think the Heroku bundler has an issue with using a branch.
No logs with source=rack-timeout-debug. Just the same old " #12] ERROR -- : listen loop error: undefined method `state=' for nil:NilClass (NoMethodError) "

@DSAMPAT heroku has no issues with git branch gems. I even deployed a test app to confirm. What are you seeing that makes you believe that? Is it failing to deploy? Failing to start? Paste any relevant logs here.

@kch I have managed to deploy. Not sure what the issue was. Could have been another gem causing the bundle issue as I am using Windows mingw-32.
I am getting this notification below, should I change anything or is this fine?
app/web.1: Rack::Timeout.timeout=: class-level settings are deprecated. See README for examples on using the middleware initializer instead.

@DSAMPAT it's just a warning, doesn't really impact anything at the moment.

We are seeing this issue also. I will try with your debug branch.

Unfortunately we are on ruby 2.0... so the beta version is not going to work. Can you make a version of the 0.3.2?

@beatjoerg it should work fine with 2.0. Any reason you think it wouldn't?

@kch Because you use some methods in the code that are not available with ruby 2.0, like super_method. I tried to backport them, but I did not arrive to fix all in the timebox I had.
To see what I "fixed" so far: https://github.com/beatjoerg/rack-timeout/commits/26e05ee40322eae527aa3fd38a8d933e3dec1819/lib/rack/timeout/legacy.rb

Oh super_method is really bad, it's 2.2 only. Ok, I'll get rid of that.

@beatjoerg 0.4.2 is out with 2.0 compatibility. I also rebased the debug branch here so it should be good to go now.
@samandmoore might work for you in jruby now too, give it a go.

@kch thanks. Still no luck for me running it because it's not ruby 1.9 compatible:
SyntaxError: /opt/rubies/jruby-1.7.24/lib/ruby/gems/shared/bundler/gems/rack-timeout-7a5914cc9734/lib/rack/timeout/core.rb:94: syntax error, unexpected tLABEL
    def initialize(app, service_timeout:nil, wait_timeout:nil, wait_overtime:nil, service_past_wait:false)

@samandmoore ok so your jruby version also doesn't support named parameters. I'll see if I can make a version of the debug branch off 0.3.2…

@samandmoore give it a go https://github.com/heroku/rack-timeout/tree/vanishing-env-info-debug-0.3.2

thanks, will give it a shot.

Is anyone actually running this debug branch in a reasonably trafficked app? I'd've expected to have some useful log lines by now.
How about this: I'll mail some heroku swag to the first person who delivers log lines that enlighten me. Help us if you like purple stuff!

I'm working on it. Just in the midst of another big change. Will likely
have results for you tomorrow :)
On Wed, Apr 6, 2016 at 18:25 Caio Chassot<EMAIL_ADDRESS>wrote:

Is anyone actually running this debug branch in a reasonably trafficked
app? I'd've expected to have some useful log lines by now.
How about this: I'll mail some heroku swag to the first person who
delivers log lines that enlighten me. Help us if you like purple stuff!
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/heroku/rack-timeout/issues/92#issuecomment-206595820

@kch Just deployed to production... Waiting for the errors...

@kch Unfortunately last time we tried this branch we almost took down our production. We have created a bypass for the error but it still happens at quite a regular frequency. ~200 per hour.

@mbasset I wonder if only injecting the hijack on a sample (like 10% or so) of the requests would make it more bearable for you. Lmk if it sounds like a good a idea and I'll add that as an option.

@kch That sounds good in theory but even having it on 10% of our traffic could cause our servers to become unstable and die albeit more slowly. We may be able to try this in our staging environment as we recently created a script to simulate some production load. However need to find time to try this out.

@mbasset well I'd make the frequency configurable. Also I believe I rewrote the debug code to be a lot nicer since you last tried it. Not sure.

@mbasset so I did it. You can set the env var RACK_TIMEOUT_HIJACK_FREQUENCY to any number between 0 and 1.0 and that'll determine the frequency.
I've also made changes so I'm hijacking even less methods, trying to stay more out of the way.

Cool I'll see when we get a chance to try this version out and see what happens.

Just FYI still have not had a chance to look into this yet. Ideally if someone else has time.

@kch Hoping to try out the branch next week. However I see it only sends warnings. In our production environment (which is the only environment this seems to happen in) how would you suggest getting the output. We are currently using an nginx/unicorn setup.

I've been working on updating the 0.3.2 branch to look like the newer one.
I tried to run it under a load test (because we only see these issues when
under reasonable load) and I haven't been able to reproduce it in
development mode. However, I was able to reproduce it in a capybara feature
spec. Unfortunately, that spec didn't have the logging in place. I am
hopefully going to try it in production in the next week or so.
On Fri, Apr 29, 2016 at 3:17 PM Matthew Basset<EMAIL_ADDRESS>wrote:

@kch https://github.com/kch Hoping to try out the branch next week.
However I see it only sends warnings. In our production environment (which
is the only environment this seems to happen in) how would you suggest
getting the output. We are currently using an nginx/unicorn setup.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/heroku/rack-timeout/issues/92#issuecomment-215853100

@kch We have been trying your latest branch out in an environment that normally causes ~100 of these errors an hour with rails 4.2.6 and it does not appear to be happening anymore. I wonder if the changes that were made to timing in that branch have solved the issue. Possibly also fixed with rails update. Will continue to monitor for the next while to see.

@kch @mbasset : Same also here, we do not see the error anymore running the debug branch. (We use also rails 4.2.6.)

@kch I have a version of the debug branch in production, and i'm seeing occasional log statements like this:
[DM4PNP]2016-05-24 07:15:53 -0400 severity=WARN, source=rack-timeout-debug info-vanish id=4773927afb3ba69e09eed01d8ae1b6fd

Unfortunately, there are no other logs associated with that id value, so I've got no call stack for you. That makes me think that the method that is unsetting the env info is one of the methods we're not redefining with the logging behavior. Thoughts?

I'm sorry for bumping this for everyone - did anyone have any success in resolving this?

Rails 4.2.6 and the latest 0.4.2 version has fixed it entirely for us.

Hi, I am suffering from the same issue with rack-timeout 0.3.2, ruby 1.9.3-p551 and Rails <IP_ADDRESS>. Unfortunately I am stuck with what I have (can't upgrade ruby or Rails.). It seems that ruby 1.9.x works with 0.3.x so I can't use 0.4.x. I will try downgrade to 0.2.x and keep you posted.

It appears this has been resolved in some way or otherwise gone away, so closing pending new reports.

I saw essentially the same error in v0.5.1 (slightly different line numbers) and with Rails v6.0.3 and gitlab-puma v4.3.3.gitlab.2.
It was preceded by
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/rack-timeout-0.5.1/lib/rack/timeout/support/scheduler.rb:73 run> terminated with exception (report_on_exception is true):
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/rack-timeout-0.5.1/lib/rack/timeout/core.rb:168:in `_set_state!': undefined method `state=' for nil:NilClass (NoMethodError)

The only (remote) clue I have to hopefully help reproduce the issue, is that Unicode characters Ç & Ã are in a commit message, that's not being displayed where it should be. I'm grasping at straws here, but is string parsing involved at any point here?

Have been having this issue since upgrade to GitLab 13.3.2-ee (13.2.x did not happen). This is with 0.5.2, which I realise is not the latest version of this package. The two instances with EE Premium licence have this problem and a service restart "fixes" it until it occurs again. Another instance without a licence uploaded appears to not have this problem, but it could just be RNG. I will raise an issue with GitLab support regarding this.
#<Thread:0x000000012b38b6f8@/var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/rack-timeout-0.5.2/lib/rack/timeout/support/scheduler.rb:73 run> terminated with exception (report_on_exception is true):
/var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/rack-timeout-0.5.2/lib/rack/timeout/core.rb:168:in `_set_state!': undefined method `state=' for nil:NilClass (NoMethodError)
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/rack-timeout-0.5.2/lib/rack/timeout/core.rb:113:in `block in call'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/rack-timeout-0.5.2/lib/rack/timeout/core.rb:115:in `block in call'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/rack-timeout-0.5.2/lib/rack/timeout/support/scheduler.rb:39:in `run!'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/rack-timeout-0.5.2/lib/rack/timeout/support/scheduler.rb:52:in `run!'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/rack-timeout-0.5.2/lib/rack/timeout/support/scheduler.rb:100:in `block (2 levels) in run_loop!'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/rack-timeout-0.5.2/lib/rack/timeout/support/scheduler.rb:100:in `each'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/rack-timeout-0.5.2/lib/rack/timeout/support/scheduler.rb:100:in `block in run_loop!'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/rack-timeout-0.5.2/lib/rack/timeout/support/scheduler.rb:81:in `loop'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/rack-timeout-0.5.2/lib/rack/timeout/support/scheduler.rb:81:in `run_loop!'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/rack-timeout-0.5.2/lib/rack/timeout/support/scheduler.rb:73:in `block (2 levels) in runner'
/var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/rack-timeout-0.5.2/lib/rack/timeout/core.rb:168:in `_set_state!': undefined method `state=' for nil:NilClass (NoMethodError)
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/rack-timeout-0.5.2/lib/rack/timeout/core.rb:113:in `block in call'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/rack-timeout-0.5.2/lib/rack/timeout/core.rb:115:in `block in call'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/rack-timeout-0.5.2/lib/rack/timeout/support/scheduler.rb:39:in `run!'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/rack-timeout-0.5.2/lib/rack/timeout/support/scheduler.rb:52:in `run!'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/rack-timeout-0.5.2/lib/rack/timeout/support/scheduler.rb:100:in `block (2 levels) in run_loop!'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/rack-timeout-0.5.2/lib/rack/timeout/support/scheduler.rb:100:in `each'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/rack-timeout-0.5.2/lib/rack/timeout/support/scheduler.rb:100:in `block in run_loop!'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/rack-timeout-0.5.2/lib/rack/timeout/support/scheduler.rb:81:in `loop'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/rack-timeout-0.5.2/lib/rack/timeout/support/scheduler.rb:81:in `run_loop!'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/rack-timeout-0.5.2/lib/rack/timeout/support/scheduler.rb:73:in `block (2 levels) in runner'

On another host the traceback is very different, so it is almost certain it is a problem in Puma or some component of GitLab and not this project, apologies for the noise. It also happened with GitLab 13.2.x fyi.

var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/abstract/connection_pool.rb:837:in `block in with_new_connections_blocked': undefined method `clear' for nil:NilClass (NoMethodError)
        from /usr/lib/ruby/2.6.0/monitor.rb:235:in `mon_synchronize'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/abstract/connection_pool.rb:833:in `ensure in with_new_connections_blocked'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/abstract/connection_pool.rb:850:in `with_new_connections_blocked'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/abstract/connection_pool.rb:752:in `with_exclusively_acquired_all_connections'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/abstract/connection_pool.rb:503:in `disconnect'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/abstract/connection_pool.rb:525:in `disconnect!'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/abstract/connection_pool.rb:1136:in `remove_connection'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/abstract/connection_pool.rb:1054:in `establish_connection'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_handling.rb:51:in `establish_connection'
        from /var/opt/gitlab/gitlab/config/initializers/active_record_lifecycle.rb:8:in `block (2 levels) in <top (required)>'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/lazy_load_hooks.rb:71:in `class_eval'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/lazy_load_hooks.rb:71:in `block in execute_hook'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/lazy_load_hooks.rb:61:in `with_execution_control'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/lazy_load_hooks.rb:66:in `execute_hook'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/lazy_load_hooks.rb:43:in `block in on_load'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/lazy_load_hooks.rb:42:in `each'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/lazy_load_hooks.rb:42:in `on_load'
        from /var/opt/gitlab/gitlab/config/initializers/active_record_lifecycle.rb:7:in `block in <top (required)>'
        from /var/opt/gitlab/gitlab/lib/gitlab/cluster/lifecycle_events.rb:147:in `each'
        from /var/opt/gitlab/gitlab/lib/gitlab/cluster/lifecycle_events.rb:147:in `call'
        from /var/opt/gitlab/gitlab/lib/gitlab/cluster/lifecycle_events.rb:114:in `do_worker_start'
        from /var/opt/gitlab/gitlab/config/puma.rb:57:in `block in _load_from'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/gitlab-puma-4.3.3.gitlab.2/lib/puma/configuration.rb:279:in `block in run_hooks'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/gitlab-puma-4.3.3.gitlab.2/lib/puma/configuration.rb:279:in `each'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/gitlab-puma-4.3.3.gitlab.2/lib/puma/configuration.rb:279:in `run_hooks'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/gitlab-puma-4.3.3.gitlab.2/lib/puma/cluster.rb:267:in `worker'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/gitlab-puma-4.3.3.gitlab.2/lib/puma/cluster.rb:138:in `block (2 levels) in spawn_workers'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/nakayoshi_fork-0.0.4/lib/nakayoshi_fork.rb:23:in `fork'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/nakayoshi_fork-0.0.4/lib/nakayoshi_fork.rb:23:in `fork'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/gitlab-puma-4.3.3.gitlab.2/lib/puma/cluster.rb:138:in `block in spawn_workers'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/gitlab-puma-4.3.3.gitlab.2/lib/puma/cluster.rb:134:in `times'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/gitlab-puma-4.3.3.gitlab.2/lib/puma/cluster.rb:134:in `spawn_workers'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/gitlab-puma-4.3.3.gitlab.2/lib/puma/cluster.rb:204:in `check_workers'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/gitlab-puma-4.3.3.gitlab.2/lib/puma/cluster.rb:487:in `run'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/gitlab-puma-4.3.3.gitlab.2/lib/puma/launcher.rb:172:in `run'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/gitlab-puma-4.3.3.gitlab.2/lib/puma/cli.rb:80:in `run'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/gitlab-puma-4.3.3.gitlab.2/bin/puma:10:in `<top (required)>'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/bin/puma:23:in `load'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/bin/puma:23:in `<main>'
/var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/abstract/connection_pool.rb:761:in `block in attempt_to_checkout_all_existing_connections': private method `select' called for nil:NilClass (NoMethodError)
        from /usr/lib/ruby/2.6.0/monitor.rb:235:in `mon_synchronize'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/abstract/connection_pool.rb:759:in `attempt_to_checkout_all_existing_connections'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/abstract/connection_pool.rb:753:in `block in with_exclusively_acquired_all_connections'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/abstract/connection_pool.rb:829:in `with_new_connections_blocked'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/abstract/connection_pool.rb:752:in `with_exclusively_acquired_all_connections'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/abstract/connection_pool.rb:503:in `disconnect'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/abstract/connection_pool.rb:525:in `disconnect!'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/abstract/connection_pool.rb:1136:in `remove_connection'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/abstract/connection_pool.rb:1054:in `establish_connection'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_handling.rb:51:in `establish_connection'
        from /var/opt/gitlab/gitlab/config/initializers/active_record_lifecycle.rb:8:in `block (2 levels) in <top (required)>'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/lazy_load_hooks.rb:71:in `class_eval'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/lazy_load_hooks.rb:71:in `block in execute_hook'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/lazy_load_hooks.rb:61:in `with_execution_control'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/lazy_load_hooks.rb:66:in `execute_hook'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/lazy_load_hooks.rb:43:in `block in on_load'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/lazy_load_hooks.rb:42:in `each'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/lazy_load_hooks.rb:42:in `on_load'
        from /var/opt/gitlab/gitlab/config/initializers/active_record_lifecycle.rb:7:in `block in <top (required)>'
        from /var/opt/gitlab/gitlab/lib/gitlab/cluster/lifecycle_events.rb:147:in `each'
        from /var/opt/gitlab/gitlab/lib/gitlab/cluster/lifecycle_events.rb:147:in `call'
        from /var/opt/gitlab/gitlab/lib/gitlab/cluster/lifecycle_events.rb:114:in `do_worker_start'
        from /var/opt/gitlab/gitlab/config/puma.rb:57:in `block in _load_from'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/gitlab-puma-4.3.3.gitlab.2/lib/puma/configuration.rb:279:in `block in run_hooks'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/gitlab-puma-4.3.3.gitlab.2/lib/puma/configuration.rb:279:in `each'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/gitlab-puma-4.3.3.gitlab.2/lib/puma/configuration.rb:279:in `run_hooks'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/gitlab-puma-4.3.3.gitlab.2/lib/puma/cluster.rb:267:in `worker'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/gitlab-puma-4.3.3.gitlab.2/lib/puma/cluster.rb:138:in `block (2 levels) in spawn_workers'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/nakayoshi_fork-0.0.4/lib/nakayoshi_fork.rb:23:in `fork'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/nakayoshi_fork-0.0.4/lib/nakayoshi_fork.rb:23:in `fork'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/gitlab-puma-4.3.3.gitlab.2/lib/puma/cluster.rb:138:in `block in spawn_workers'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/gitlab-puma-4.3.3.gitlab.2/lib/puma/cluster.rb:134:in `times'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/gitlab-puma-4.3.3.gitlab.2/lib/puma/cluster.rb:134:in `spawn_workers'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/gitlab-puma-4.3.3.gitlab.2/lib/puma/cluster.rb:204:in `check_workers'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/gitlab-puma-4.3.3.gitlab.2/lib/puma/cluster.rb:487:in `run'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/gitlab-puma-4.3.3.gitlab.2/lib/puma/launcher.rb:172:in `run'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/gitlab-puma-4.3.3.gitlab.2/lib/puma/cli.rb:80:in `run'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/gems/gitlab-puma-4.3.3.gitlab.2/bin/puma:10:in `<top (required)>'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/bin/puma:23:in `load'
        from /var/opt/gitlab/gitlab/vendor/bundle/ruby/2.6.0/bin/puma:23:in `<main>'


Lifecycle fixes

Fixes a handful of surprising behaviours in AbstractApplication, DynamicGroup and BasicStartable.

One possibly surprising new behaviour from 1e44522 involves the status of a BasicStartable when its children restart. I'll use this blueprint as an example:
location: localhost
services:
- type: org.apache.brooklyn.entity.stock.BasicStartableImpl
  brooklyn.children:
  - type: org.apache.brooklyn.entity.software.base.EmptySoftwareProcess
    brooklyn.config:
      postLaunchCommand: "exit 1"
      startTimeout: 2s

Previously, once the ESP entity has failed once the BasicStartable is always on fire, even if postLaunchCommand were modified to something sensible. With the changes in this pull request when the ESP restarts the BasicStartable's state transitions to RUNNING, then back to ON_FIRE when the post-launch command fails for the second time. I discussed this with @justin.thompson. We felt that though the new behaviour isn't entirely satisfactory it is less wrong than before.

@neykov I've updated per your comments.

Thanks @sjcorbett, merging.


Add Gen.either

And make the Arbitrary instance for Either delegate to it.

If we merge #494 we can close this.

Thanks @ceedubs! Sorry for how long this sat around.


Refactor use of **kwargs in PL classes for better LightningCLI support

Proposed refactor

All the __init__ parameters from classes in the pytorch-lightning repo that are susceptible to be used via LightningCLI should be resolvable by jsonargparse: parameter name, type and docstring description.
A list of potential classes that would be good to refactor is the following. Probably each class needs to be considered separately and some might have higher priority than others.

CometLogger
NeptuneLogger
TensorBoardLogger
WandbLogger
DDPStrategy
DDPSpawnStrategy
PyTorchProfiler
...

See Possibilities section below for ideas on how to refactor.
Motivation

This has been a recurrent issue, for example:

https://github.com/PyTorchLightning/pytorch-lightning/discussions/8561
https://github.com/PyTorchLightning/pytorch-lightning/issues/11574
https://github.com/PyTorchLightning/pytorch-lightning/issues/9887#issuecomment-1018532746
https://github.com/PyTorchLightning/pytorch-lightning/issues/8008#issuecomment-945540010

There is a proposal to allow specifying values for unresolved parameters which would skip validation https://github.com/omni-us/jsonargparse/issues/114. The downside is no support for several nice features (see Pitch). This can be a solution for some cases. But it is not be the ideal solution, particularly for classes in the pytorch-lightning repo which can be more easily considered for modifications.
Pitch

With this refactor all features from the CLIs become available:

Validation of values based on parameter types and early error messages.
Description of parameters in the help of CLIs.
Inclusion in reference config files obtained via --print_config.
Linking of arguments.

Possibilities

Add all parameters to the class. This is how several people have been solving this issue, e.g. https://github.com/PyTorchLightning/pytorch-lightning/issues/9887#issuecomment-1018532746

Advantages: Very simple solution. All Pitch features available. No need for deprecations or change how the classes are used.
Disadvantages: Duplication of code. The parameters to where these **kwargs might change, thus creating problems.

Have a specific parameter with dict type. For example in the case of TensorBoardLogger there could be a parameter summary_writer_kwargs: Dict[str, Any]. The existing **kwargs would be deprecated, showing a warning if used.

Advantages: Also it is more clear what this parameter is for, unlike a generic **kwargs.
Disadvantages: No support for features listed in Pitch. Introduces deprecation. Need to change existing code, e.g. from param1=val, ... to summary_writer_kwargs=dict(param1=val, ...).

Have a specific parameter with a dataclass type. For example in the case of TensorBoardLogger there could be a parameter summary_writer_options: SummaryWriterOptions. The dataclass would be automatically generated from a signature, thus avoiding code duplication or discrepancies in parameters. See below possible function that could create these dataclasses.

Advantages: All Pitch features available.
Disadvantages: Introduces deprecation. Need to change existing code, e.g. from param1=val, ... to first have an import from ... import SummaryWriterOptions and then when used ... summary_writer_kwargs=SummaryWriterOptions(param1=val, ...)`.

import inspect
from typing import Any, Set
from dataclasses import make_dataclass, field

def dataclass_from_signature(name: str, func, skip: Set = None):
    """Creates a dataclass using as fields parameters from the signature of some callable.

    Args:
        name: How the new class should be called, i.e. value to set in ``__name__``.
        func: The callable from which to get the signature.
        skip: Names of parameters to exclude from the signature.

    Example:
        ``MyData = dataclass_from_signature('MyData', MyClass.__init__, skip={'self', 'paramX'})``
    """
    fields = []
    params = list(inspect.signature(func).parameters.values())
    for param in params:
        if skip and param.name in skip:
            continue
        field_info = [param.name, Any if param._annotation == inspect._empty else param._annotation]
        if param.default != inspect._empty:
            field_info.append(field(default=param.default))
        fields.append(tuple(field_info))
    new_dataclass = make_dataclass(name, fields)
    # TODO: Add docstring with description of fields.
    return new_dataclass

Similar to (3) but instead of a dataclass, it would be a normal class also automatically generated. The __init__ would define the parameters, but it would ignore them. This class would be used as a parent class, so jsonargparse would resolve the parameters via inheritance. For example for TensorBoardLogger the definition could be something like class TensorBoardLogger(SummaryWriterOptions, LightningLoggerBase):.

Advantages: All Pitch features available. No need for deprecations or change how the classes are used.
Disadvantages: A bit more complex solution and feels a bit more hacky (though might not be).

Please propose more possibilities.

The deprecations mentioned above could be optional. It wouldn't be a problem to keep the new parameter but also the existing **kwargs. This way there is not need for people to change their existing code.
The dataclass_from_signature function very likely will be added to and maintained in jsonargparse irrespective of this.
Additional context

If you enjoy Lightning, check out our other projects! ⚡

Metrics: Machine learning metrics for distributed, scalable PyTorch applications.

Lite: enables pure PyTorch users to scale their existing code on any kind of device while retaining full control over their own loops and optimization logic.

Flash: The fastest way to get a Lightning baseline! A collection of tasks for fast prototyping, baselining, fine-tuning, and solving problems with deep learning.

Bolts: Pretrained SOTA Deep Learning models, callbacks, and more for research and production with PyTorch Lightning and PyTorch.

Lightning Transformers: Flexible interface for high-performance research using SOTA Transformers leveraging Pytorch Lightning, Transformers, and Hydra.

cc @borda @justusschock @awaelchli @akihironitta @rohitgr7 @tchaton @carmocca

I don't think (2) or (3) will happen because, from past experience, people are really allergic to having to create these extra objects. And since they would be created dynamically, users could not easily figure out what arguments can be passed and what they do.
My preference is doing (1) for the popular classes used in the CLI to reap the benefits described in your pitch.

I don't think (2) or (3) will happen because, from past experience, people are really allergic to having to create these extra objects. And since they would be created dynamically, users could not easily figure out what arguments can be passed and what they do.
My preference is doing (1) for the popular classes used in the CLI to reap the benefits described in your pitch.

Don't underestimate the downsides of (1). For example for PyTorchProfiler even the docstring says that the parameters depend on the pytorch version. Defining parameters of a class conditional on the installed pytorch version for sure would be ugly.
If (3) is done without deprecation of the current **kwargs people would not need to use an extra object. The new parameter could be intended only for the CLIs and described as such in the docstring. The difference would be that these settings in the yaml would be indented in a section, e.g. in summary_writer_kwargs instead of in __unresolved__.
I have just added a fourth option that could also be interesting.

To me, a killer feature of jsonargparse (and consequently the LightningCLI) is that you don't need to adapt your code to your parser, instead the parser integrates to your code (by using the annotations, docstrings, ...).
To me, doing (2), (3), or (4) is adapting the code to fit the parser needs. If the LightningCLI did not exist, would these changes be valuable by themselves? Probably not.
(1) is somewhat valuable because the user avoids 1 jump to read the argument annotations and docstrings, at the cost of duplication. That's why it's my preference.

Defining parameters of a class conditional on the installed pytorch version for sure would be ugly.

I agree. We could keep the code as-is for these tricky classes and just let go of the validation.

I have just added a fourth option that could also be interesting.

Could this option be done by jsonargparse behind the scenes?

To me, a killer feature of jsonargparse (and consequently the LightningCLI) is that you don't need to adapt your code to your parser, instead the parser integrates to your code (by using the annotations, docstrings, ...).

Indeed this has been the objective of jsonargparse and certainly improving its parameter discovery feature is another possibility to address this LightningCLI recurring issue, now it is (5) above. However, there are endless ways in which people might use **kwargs internally in their code. jsonargparse would need to analyze the source code to trace down the **kwargs. I suppose that with the https://docs.python.org/3/library/ast.html module, analyzing the source code is doable. Though, targeting to support all possible **kwargs uses would be extremely complex and very difficult to achieve in practice. If not all possible **kwargs uses are supported, then unfortunately people need to adapt the code to the parser, if in their case the parameter discovery does not work.
Going this route for certain will require way more effort and time. I have never used ast and also haven't thought it through. It might be going down a rabbit hole and introduce difficult to fix problems. Almost certain that it would not be a support for any **kwargs use. It probably would be a very small number of easy to explain support cases, such that when it does not work, people are able to understand why and modify accordingly.

To me, doing (2), (3), or (4) is adapting the code to fit the parser needs. If the LightningCLI did not exist, would these changes be valuable by themselves? Probably not.

In my opinion it depends on the case and how you look at it. Having (2) or (3) and a parameter called summary_writer_kwargs leads to easier to understand code and could be considered better practice by some people. But anyway, deciding not to adapt the code just because of value under the assumption that LightningCLI did not exist ignores the issue. The fact is that LightningCLI exists and there is a recurring issue that affects many users. An adaptation in PL might be justified to resolve the issue even if it is only temporal.

(1) is somewhat valuable because the user avoids 1 jump to read the argument annotations and docstrings, at the cost of duplication. That's why it's my preference.

That is fine. I am just trying to list out all the possibilities so that better decision can be made.

An adaptation in PL might be justified to resolve the issue even if it is only temporal.

I can get on board with this, but this disqualifies (2) and (3) as they would require long deprecation processes.

I will look into ast and later let you what could be done. Regarding (1) it also has the advantage of being simple enough to be implemented by any contributor. And definitely would provide a better user experience than https://github.com/omni-us/jsonargparse/issues/114.

An update about this. I have been looking at option (5). As I thought, it is considerably complex. Still, I think it will be eventually implemented in jsonargparse. Though this will take time. Thus, (1) as interim solution could be considered.


feat(chart_downloader): Use cached chart if possible in chart_downloader.go

closes https://github.com/helm/helm/issues/13211
What this PR does / why we need it:
It prevents a chart from loading if it has already been loaded
If applicable:

[Y] this PR contains unit tests

@banjoh hi! What do you think about the PR?

Hi @joejulian  ,
I noticed that this pull request has been pending for a while. Is there anything more needed from my side? Please let me know if there are any updates or additional changes required.
Thanks!

Hi @robertsirc
I noticed that this pull request has been pending for a while. Is there anything more needed from my side? Please let me know if there are any updates or additional changes required.
Thanks!

Hello @mattfarina, @banjoh  , just a gentle reminder about this PR created months ago. If possible, could it be reviewed before the next Helm release? I’d appreciate any feedback to help get it ready in time. Thank you!

Hello @mattfarina, just a gentle reminder about this PR created months ago. If possible, could it be reviewed before the next Helm release? I’d appreciate any feedback to help get it ready in time. Thank you!


feature: add file detection for pretranspiled sass, less, scss files

If we use Less, Scss or Sass, then there may not be a CSS file. Using the extension recognition, it is possible to touch the relevant style file that contains @windicss.

A bit confused, shouldn't this line get the current file path already?
https://github.com/antfu/postcss-windicss/blob/15f5970033b974510a4330a239e7587d7a065ed7/src/index.ts#L32-L32

So how about we make an option to pass entry points manually for this scenario? Meaning
// postcss.config.js
module.exports = {
  plugins: {
    'postcss-windicss': {
      touches: [
        'a/b.postcss'
      ]
    },
  },
}


Clear the errors

Is there a way to clear the errors using any utility? I'm currently having a product request to make a functionality like this but couldn't figure it out yet

Hi @danestves. Will formElement.reset() works? Or if you are trying to "hide" the errors?

What is your usecase? To clear all errors, one way I can think of now is to use a custom intent and have the parser returns a submission with no error whenever it sees that intent. But all errors will come back once it revalidates.

What is your usecase? To clear all errors, one way I can think of now is to use a custom intent and have the parser returns a submission with no error whenever it sees that intent. But all errors will come back once it revalidates.

I have some checkboxes to accept the terms, when the user doesn't check anything and click on submit the errors appear, until here is perfect; the client wants that when the user checks a checkbox the error disappear, but if he unchecks again the error doesn't appear until he hit the submit button (I'm using the validations on submit)

I think Conform is quite limited on this aspect and probably need to be improved 😅 For now, I see 2 solutions:
(1) Just make an additional state to hide the error you want, or
(2) Opt-out from Conform revalidation (i.e. shouldRevalidate: 'onSubmit') and customize the revalidation behaviour yourself. This means setting up an input / blur handler yourself and call requestIntent(form, validate(fieldName)) only when appropriate.

Yeah, actually I'm kind of angry with the requirement because that's a tricky behavior, and I'm going to put that ticket on my team as blocked until they reviewed more. Thanks for the answers and we can close this ticket!

All good. Let me know if you need an example especially for solution 2. I have been rethinking about the error handling recently and this reminds me what I should also covered for the new design. Thanks for the question!


Conditional assignment

:+1:

31st of July? :-) This has been in the works for quite a while. :-)

31st of July? :-) This has been in the works for quite a while. :-)

Yeah, I have been working on this on and off for quite a while. The design has completely changed on it at least twice.

The code is a bit dense (a few comments here and there might be useful), but overall it looks OK to me. I noticed the tests were pretty exhaustive and that's the most important thing. :+1:

I will add some comments and submit a new PR.


Fix error of jest test over node 11.11

fix #6591
I think I can solve the issue as follows. It is a problem to change the version of the module.

Sorry. I can not solve the "kitchensink-eject" test.

I do not know why the code is the same but the results are different.
3rd commit
Fix error of resolver not found in travis-ci c55a951e1ed2a7426316fa3e484d61c022e3fe0c:
https://travis-ci.org/facebook/create-react-app/builds/503219173?utm_source=github_status&utm_medium=notification

5th commit
Update babel-jest version from 23.6 to 24.3 6bbdc707d250adb58b282dd126e3ebaea5b71b93:
https://travis-ci.org/facebook/create-react-app/builds/503237557?utm_source=github_status&utm_medium=notification

This is a dupe of #6278.


feat: add InteractionHandle

This PR fixes #903
Motivation

This PR integrates InteractionManager with TabView Pager
Test plan

yarn
yarn lint
yarn test

Hey, @Naturalclar
Can you explain do we really need this?
/@janicduplessiss

This will prevent things that use InteractionManager from doing expensive work during transitions. An example is FlatList that doesn't render new rows during interactions.

@osdnk Sorry for the late response!
as @janicduplessis mentioned, this PR's intention is to setup InteractionManager to prevent heavy loads during transitions.
Since react-native-reanimated and react-native-gesture-handler doesn't integrate with InteractionManager, it would be nice to have the handler in this package.


DB stat on number of monitor peers

Description of PR

What component(s) does this PR affect?

[X] Back-End (Database, Microservices, Containers, etc)
[X] Front-End (Flask, API, etc)
[X] Docs
[ ] Build System

Does the PR require changes on other components? If yes, please mark the components:

[ ] Back-End (Database, Microservices, Containers, etc)
[ ] Front-End (Flask, API, etc)
[ ] Docs
[ ] Build System

Related Issue

Resolves #152
Solution

Pre-load the set of monitor peers from the stored DB BGP updates. Load this into redis, and update
redis whenever a new BGP update is seen. Update DB only if the redis set actually changes.
Type

[ ] Bug fix (non-breaking change which fixes an issue)
[X] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Docs update
[ ] None of the above

Checklist:

[X] I have read the contributing guide and my code conforms to the guidelines.
[X] This change requires a change in the documentation.
[ ] I have updated the documentation accordingly.

TODOS:
[ ] Update monitor peer counts in DB
[ ] Add new stat to frontend overview stats

TODO: slight update to the wiki before merging


Object with Role ACL Write Permissions Issue

Hi,
I have ran into an issue with the write permissions on a class object. When I try to update an object that has write permissions set I get an Object Not Found error. If I remove the write permission I am able to successfully update the object. The read permissions on the object seem to be working normally. Parse Server is running on AWS and the database in hosted at MongoLab.
Object in MongoDB:
{     "_id": "AVNXTbPaSg",     "installDate": {         "$date": "2016-02-12T00:00:00.000Z"     },     "location": "Test ACL",     "type": "Interior",     "_p_company": "Company$4N9uDwBqee",     "truckName": "Truck Name",     "startTime": "06:15",     "_updated_at": {         "$date": "2016-02-12T20:34:40.468Z"     },     "_created_at": {         "$date": "2016-02-11T22:20:51.338Z"     },     "_rperm": [         "role:Role Name"     ],     "_wperm": [         "role:Role Name"     ] }
Code to update object:
`strJobId = $('#jobId').val();
// Create the object.
  var Job = Parse.Object.extend("Job");
  var jobObject = new Job();
  jobObject.id = strJobId;

  jobObject.set("location", "updated..yo!");

  jobObject.save(null, {
    success: function(job) {

      console.log(job);
    },
    error: function(job, error) {

      console.log('Failed to update object, with error code: ' + error.message);
    }
  });`

Browser Console Error:
POST http://myparserver.elasticbeanstalk.com/parse/classes/Job/AVNXTbPaSg 404 (Not Found)
myjs.js:408 Failed to update object, with error code: Object not found.
Thanks,
Zain

Will be fix with this pull request

@flessard Thanks!


REG_CREATE_KEY_INFORMATION[_V1] Absolute path character

If the path is absolute, this structure contains a fully qualified path that starts with the "" character.
If the path is relative, the path starts with a character other than ""

Symbol is not displayed, character "\" escaping is required
REG_CREATE_KEY_INFORMATION (https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/wdm/ns-wdm-_reg_create_key_information) - same problem

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 577c6e3c-5587-723c-d8f0-0b409da989b4
Version Independent ID: af591655-5cf7-51b0-5156-d1357cd76846
Content: _REG_CREATE_KEY_INFORMATION_V1
Content Source: wdk-ddi-src/content/wdm/ns-wdm-_reg_create_key_information_v1.md
Service: unspecified
Product: windows-hardware
GitHub Login: @windows-driver-content
Microsoft Alias: windowsdriverdev

Pull request: #95

Assuming this issue preceded your PR, thanks again


MediaRecorder doesn't work

Steps to reproduce
Tell us about your environment:

Puppeteer version: 1.19.0
Platform / OS version: Win10 x64
URLs (if applicable): -
Node.js version: 10.16.0

What steps will reproduce the problem?
I use puppeteer to accept and send back user's media stream (video + audio), it works, user can see his stream returned from server.
I want to record user stream inside puppeteer:
const mediaRecorder = new MediaRecorder(<user's stream from RTCPeerConnection>);
mediaRecorder.start(100);
mediaRecorder.addEventListener('dataavailable', ev => {
  console.log(ev.data.size);
});

// in another place I call mediaRecorder.stop();

What is the expected result?
I expected that dataavailable event will be fired every 100ms with of stream and after I call stop()
ev.data.size shouldn't be zero
What happens instead?
dataavailable event was fired once(on stop()) and ev.data.size is 0 (ev.data.type is some right codec)
The same code for user's local stream works fine in browser (Chrome 76.0.3809.100)

Update:
Idk why, but if I add video tag to the document with this stream as srcObject - all works ¯\_(ツ)_/¯
This is how it should work? Can I do something to not add elements to the document?

Update:
Idk why, but if I add video tag to the document with this stream as srcObject - all works ¯\_(ツ)_/¯
This is how it should work? Can I do something to not add elements to the document?

Can you tell me how you went about this in puppeteer? I'm trying to record a canvas and data size is always 0.

Any solutions?

did anyone figure out how to resolve this issue?


BSON causes POST to fail? Never reaches desired Web API endpoint

I'm able to successfully execute a simple post using Swagger against my .NET Web API project:
{
  "application_version": "3.2",
  "device_type_id": 2,
  "allergens": [],
  "preferences": [],
  "demographics": []
}

However, attempting to send the same request via RestSharp portable library yields an HTTP 500 error. The request never reaches the desired endpoint.  Sample code below.. Please note that the ConsumerDto seen below uses JsonProperty annotations to convert property names to snake case, e.g. ApplicationVersion to application_version.
var consumer = new ConsumerDto
{
	ApplicationVersion = "3.2",
	DeviceTypeId = 2,
	Allergens = new List<int>(),
	Demographics = new List<DemographicDto>(),
	Preferences = new List<int>()
};

var request = new RestRequest("api/consumer", Method.POST);
request.AddJsonBody(consumer);
await _client.Execute<int>(request);

I assume this is because the ISerializer interface returns a byte[] (from what I understand, binary JSON or BSON) rather than the JSON representation of the object. I've tried adding config.Formatters.Add(new BsonMediaTypeFormatter()); to my Web API project, but it made no difference.
What am I doing incorrectly?
Thanks

RestSharp.Portable doesn't support BSON. The byte[] is the byte sequence for the given character set (encoding) and your data is sent as JSON (usually with UTF-8 encoding). According to your example, the RestClients BaseUrl must end in a /. When you - for example - have a base URL like http://localhost/test and a relative request URL like api/consumer, then the combined URL would be http://localhost/api/consumer, which probably isn't what you want.
Other than that, the only thing I can suggest is, that you might take a look at the raw request using Fiddler.
PS: I see that you use AddJsonBody. This function uses an internal (non-configurable) instance of the JsonSerializer and not the one configured in the RestRequest. When you want to use RestRequests serializer, then you should use AddBody instead of AddJsonBody.

@fubar-coder Thanks for your response. I fought with this all day yesterday and a bit this morning and found that a Web API web config issue was causing HTTP 500 errors for requests that failed authentication (which wasn't logged via ELMAH), rather than returning a 401. So, this is not a bug at all, but rather a configuration issue on our side. Sorry for the trouble!


Object.observe adapter

Can someone write an example of implementing an adapter using object.observe?
10x!

This is what I've been using but I don't know if it will help you
rivets.adapters['.'] = {
observe: function(obj,keypath,callback){
Object.observe(obj,callback);
},
unobserve: function(obj,keypath,callback){
Object.unobserve(obj,callback);
},
get: function(obj,keypath){
return obj[keypath];
},
set: function(obj,keypath,value){
obj[keypath] = value;
}
};

I think my adapter suffers from this bug:
https://github.com/mikeric/rivets/issues/83
where you can't set formatters to things

Closing as not a bug or issue with rivets itself


Update to Cancel Bolus Action

Update to HomeRootView.swift to add a button that encompasses both the bolusing icon and the text “Bolusing” to make canceling a bolus easier to tap when needed.
Visually, the UI is identical to previous versions.

Initial attempts to copy/paste from Xcode to Github caused build issues (Closed initial PR #343 ). I merged it successfully by saving and uploading the entire HomeRootView.swift source code. Because of this, I recognize it’s difficult to see what I changed. Edited lines are 315-329.


✨ Implement /manage command

Codecov Report
Attention: Patch coverage is 65.21739% with 8 lines in your changes missing coverage. Please review.

Project coverage is 27.95%. Comparing base (375b0c5) to head (c1ab95f).

Files with missing lines
Patch %
Lines

src/db.rs
78.94%
0 Missing and 4 partials :warning:

src/telegram/methods.rs
0.00%
3 Missing :warning:

src/telegram/objects.rs
0.00%
1 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##           master      #13      +/-   ##
==========================================
+ Coverage   26.89%   27.95%   +1.06%
==========================================
  Files          22       22
  Lines         859      880      +21
  Branches      859      880      +21
==========================================
+ Hits          231      246      +15
- Misses        577      579       +2
- Partials       51       55       +4

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


[ISSUE #4098] Method may fail to clean up stream or resource[WatchFileManagerTest]

Fixes #4098.
Motivation
Method may fail to clean up stream or resource
Explain why you want to make the changes and what problem you're trying to solve.
Modifications
Used try with resources to manage resources
Documentation

Does this pull request introduce a new feature? (no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)
If a feature is not applicable for documentation, explain why?
If a feature is not documented yet in this PR, please create a followup issue for adding the documentation

please check checkstyle.

Hi @kyooosukedn , the issue has been accomplished in https://github.com/apache/eventmesh/pull/4716. Do you have any additional information to share? Feel free to share your latest insights with us. If you feel that your issue has been resolved, you are welcome to close it. We sincerely appreciate your contributions to Apache EventMesh.

It seems like the issue is closed properly. I will close this :)


Git push hook isn't working when remote branch wasn't created yet

Describe the bug
Git push hook isn't working when remote branch wasn't created yet
To Reproduce
Check out to a new local branch, commit some changes and push.
Expected behavior
Git hook should execute normally.

Fixed


Rocket Beta <IP_ADDRESS> (#242) for Unturned <IP_ADDRESS> Large Glitches

No one can see eachother! <----------- Means all players are invisible to eachother!
We have large amounts of lag! <----- That never happened untill Rocket Beta <IP_ADDRESS>

#71


Edge compute setting is not loaded correctly

When going from develop to edge compute, the setting isn't loaded.
This come from a few related issues:

PublicSettingViewModel doesn't set the enableEdgeComputeFeatures.
PublicSetting API handler doesn't return EnableEdgeComputeFeatures

Closed via #3665


awscli2: 2.12.7 -> 2.13.2

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for awscli2 is: Unified tool to manage your AWS services
meta.homepage for awscli2 is: https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html
meta.changelog for awscli2 is: https://github.com/aws/aws-cli/blob/2.13.1/CHANGELOG.rst
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.13.1 with grep in /nix/store/nsvw8jl20v0jxiwik038bm92348lz5gk-awscli2-2.13.1
found 2.13.1 in filename of file in /nix/store/nsvw8jl20v0jxiwik038bm92348lz5gk-awscli2-2.13.1

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath
awscli2
liquidsoap

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/nsvw8jl20v0jxiwik038bm92348lz5gk-awscli2-2.13.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A awscli2 https://github.com/r-ryantm/nixpkgs/archive/121e7cfbde55b105c3b1c73ee94469693622f5b8.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/nsvw8jl20v0jxiwik038bm92348lz5gk-awscli2-2.13.1
ls -la /nix/store/nsvw8jl20v0jxiwik038bm92348lz5gk-awscli2-2.13.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

2 packages built:

awscli2
liquidsoap

Maintainer pings
cc @bhipple @davegallant @bryanasdev000 @devusb @anthonyroussel for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for awscli2 is: Unified tool to manage your AWS services
meta.homepage for awscli2 is: https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html
meta.changelog for awscli2 is: https://github.com/aws/aws-cli/blob/2.13.2/CHANGELOG.rst
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.13.2 with grep in /nix/store/qh0mn1drk4a2hh3aa71kiicl2z43r7w3-awscli2-2.13.2
found 2.13.2 in filename of file in /nix/store/qh0mn1drk4a2hh3aa71kiicl2z43r7w3-awscli2-2.13.2

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath
awscli2
liquidsoap

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/qh0mn1drk4a2hh3aa71kiicl2z43r7w3-awscli2-2.13.2 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A awscli2 https://github.com/r-ryantm/nixpkgs/archive/5e17b5adf1707ce4c68b2702f6bc2db4bbda75f3.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/qh0mn1drk4a2hh3aa71kiicl2z43r7w3-awscli2-2.13.2
ls -la /nix/store/qh0mn1drk4a2hh3aa71kiicl2z43r7w3-awscli2-2.13.2/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

2 packages built:

awscli2
liquidsoap

Maintainer pings
cc @bhipple @davegallant @bryanasdev000 @devusb @anthonyroussel for testing.


be able to print through WSL

Environment
Windows build number: Microsoft Windows [Version 10.0.19041.330][run `[Environment]::OSVersion` for powershell, or `ver` for cmd]
Your Distribution version: [On Debian or Ubuntu run `lsb_release -r` in WSL] ubuntu 20.04
Whether the issue is on WSL 2 and/or WSL 1: [run `cat /proc/version` in WSL]Linux version 4.19.84-microsoft-standard (oe-user@oe-host) (gcc version 8.2.0 (GCC)) #1 SMP Wed Nov 13 11:44:37 UTC 2019.

Steps to reproduce

I am trying to install the driver of my printer, but it doesn't complete successfully.
below is the error i am getting.
https://i.stack.imgur.com/UyhZ2.jpg
i am running ./hplip-3.20.3.run

Expected behavior
the installation is supposed to go through without having an error.

Actual behavior
it says python3-pyqt5 is missing, however when trying to install that one, it says it's already installed.

I cannot install the driver, therefore my application cannot work properly.
Thanks.

"Trying to install the driver of my printer" is not a repro, and that jpg hyperlink doesn't resolve to an image. But lets call this spiritually equivalent #2195 if it is a USB printer, and a lengthy serverfault question if it is a network printer. For the latter it is often better to frame the question something like "how do I install a printer on a headless Linux container" over there rather than WSL.


readinessProbe & livenessProbe?

There is currently no readiness or liveness probes.  Can we consider adding something like this?
        readinessProbe:
          tcpSocket:
            port: pms
          initialDelaySeconds: 5
          periodSeconds: 10
        livenessProbe:
          tcpSocket:
            port: pms
          initialDelaySeconds: 15
          periodSeconds: 20

@billimek can you close?


Breaking change in deserialization behavior for classes using [JsonExtensionData]

Consider the following class:
public class Item
{
    [JsonExtensionData]
    public IDictionary<string, JToken> ExtensionData;

    public IEnumerable<string> Foo
    {
        get { yield return "foo"; yield return "bar"; }
    }
}

It has three important features:

It has an extension data
It uses a read only property that cannot be easily deserialized.
It needs to be serialized with TypeNameHandling = TypeNameHandling.Auto

This code will fail:
var jsonSerializer = new JsonSerializer
{
    TypeNameHandling = TypeNameHandling.Auto
};
var stringWriter = new StringWriter();
jsonSerializer.Serialize(stringWriter, new Item());
var str = stringWriter.GetStringBuilder().ToString();
Console.WriteLine(str);
var deserialize = jsonSerializer.Deserialize<Item>(new JsonTextReader(new StringReader(str)));

The underlying problem happened in this commit:
https://github.com/JamesNK/Newtonsoft.Json/commit/3536c768730d7dbfe642874404ab43b2ce6b2256
More specifically, this change:
https://github.com/JamesNK/Newtonsoft.Json/commit/3536c768730d7dbfe642874404ab43b2ce6b2256#diff-0a9aaee3fa9afeb40961d1adf9202fc1R1789
The problem is that the code is trying to materialize the value, while before we just got the raw json value.
This is what the json looks like:
{"Foo":{"$type":"ConsoleApplication1.Item+<get_Foo>d__2, ConsoleApplication1","$values":["foo","bar"]}}

Because this value cannot be deserialize, this fails with an error:
Unhandled Exception: Newtonsoft.Json.JsonSerializationException: Error setting value in extension data for type 'Console
Application1.Item'. Path 'Foo.$values', line 1, position 89. ---> Newtonsoft.Json.JsonSerializationException: Cannot cre
ate and populate list type ConsoleApplication1.Item+<get_Foo>d__2. Path 'Foo.$values', line 1, position 89.

I reverted this line in our own copy of JSON.Net, because it is enough for our needs, but I'm not sure how to actually resolve it in JSON.Net, since this might create compatability issues if just reverted.
The ideal manner would be to have a way of saying, I don't need objects here, so if this fails, just let me run.
Maybe changing the extension data setter to get the json and a delegate to actually materialize the value?

Fixed https://github.com/JamesNK/Newtonsoft.Json/commit/92102f9a3352ca52d2bbbf0cd1eadae0783970ea


Failed to install

Pls help me. How I need to do this?

retry now

yeah nice thx

what you changed?

what you changed?

Released the plugin. You tried when I just copied plugin template to work on


Add term "gross national electricity consumption"

Description of the issue
Eurostat Energy glossary uses the term gross national electricity consumption which we should add.
Ideas of solution
Add gross national electricity consumption as subclass of gross inland energy consumption
Definition from Eurostat Energy glossary : Gross national electricity consumption includes the total gross national electricity generation from all fuels (including auto-production), plus electricity imports, minus exports. Auto-production is defined as a natural or legal person generating electricity essentially for his/her own use. Gross electricity generation is measured at the outlet of the main transformers, i.e. it includes consumption in the plant auxiliaries and in transformers.
If we implement it, we should add gross electricity consumption as alternative terms.
Workflow checklist

[ ] I discussed the issue with someone else than me before working on a solution
[ ] I already read the latest version of the workflow for this repository
[ ] The goal of this ontology is clear to me

I am aware that

[ ] every entry in the ontology should have a definition
[ ] classes should arise from concepts rather than from words

All the subclasses of consumption have the relation 'has quantitiy value' some 'energy amount value'. Is this possible for a process to have a quantity value?

for dev meeting 30:
change existing class:
Gross inland energy consumption is a quantity value measuring the total consumption of energy in a spatial region (e.g. a country).
new class:
Gross national electricity consumption is a quantity value measuring the consumption of electrical energy in a spatial region (e.g. a country), including gross electricity generation plus electricity imports, minus electricity exports. It is part of the gross inland energy consumption.
relation:  Gross national electricity consumption 'is quantity value of' energy consumption value
new class:
Energy consumption value is an energy quantity value that measures the energy consumption over a temporal duration.
Do you still agree or should we implement some kind of hierarchy to the classes? e.g. make Gross national electricity consumption a subclass of Gross inland energy consumption?

Slight modification: An energy consumption value is an energy quantity value that measures the energy consumption over a temporal duration.

new class:
Energy consumption value is an energy quantity value that measures the energy consumption over a temporal duration.

Now, temporal duration is used in the definition. Should we implement temporal duration and time duration as alternative terms of duration?

new class:
Energy consumption value is an energy quantity value that measures the energy consumption over a temporal duration.

Now, temporal duration is used in the definition. Should we implement temporal duration and time duration as 'alternative terms' for duration?

If I remember correctly, we spoke in the OEO dev meeting only about time duration as alternative term to duration. I suggest that we add time duration and use it in this definition: An energy consumption value is an energy quantity value that measures the energy consumption over a time duration.


Could not find class rvm

I'm trying to provision a box with vagrant
I've added puppet-rvm as a git submodule in my modules dir
and the following puppet scripts in the manifest dir:
#init.pp
group { "puppet":
ensure => "present",
}
Exec { path => [ "/bin", "/usr/bin" ] }
include "scm"
include "openjdk"
include "jenkins"
include "install-rvm"
#install-rvm.pp
class install-rvm {
include rvm
rvm::system_user { deployer: ; }
if $rvm_installed == "true" {
rvm_system_ruby {
'ruby-1.9.3-p194':
ensure => 'present',
default_use => true;
}
}
}
But I get the error
"Could not find class rvm for oneiric32 at /tmp/vagrant-puppet/manifests/install-rvm.pp:2 on node oneiric32"
Is there a method for debugging why this isn't working?

checking the module directory permissions help