-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compile error from scout when instrumenting code that uses numbered parameters in blocks #330
Comments
Thanks for the report @DanielJoyce - we'll investigate. To confirm, you explicitly enabled AutoInstruments via config setting, correct? |
Well when we view tracing info on the website, it shows the percent of time spent in auto-instrumented code. We use the default settings. # This configuration file is used for Scout APM.
common: &defaults
monitor: true
# TODO: The name needs to be split between development and production.
production:
<<: *defaults
development:
<<: *defaults
monitor: false
test:
<<: *defaults
monitor: false So its whatever the default settings do. |
It looks like auto_instrument defaults to false, so I don't know what it is doing then... From the docs:
|
Can you check to see if it's being enabled in your environment variables? It would be |
It looks like we turn it on programmatically.
By adding this line to various code paths |
Hrm, this wouldn't turn on the AutoInstruments feature. This is just attaching pieces of data to the detailed traces we collect.
I'm not having any luck reproducing the compile error on Ruby 2.7 with the same code. Would it be possible to share the entire method code where this |
Okay, yes, it looks like we do have it turned on via the env var. |
I just added SCOUT_AUTO_INSTRUMENTS=true before running our tests, and seeing errors in the exact same spot
Bit clearer than the GCP logs. I will see what needs to be done on our end to get more info |
Producing minimal test case... |
So it appears what is going is scout is trying to insert a call here
producing
The argument to all? is getting displaced. |
Hmm, the use of _1 in the block call to all? seems to be what is tripping it up. |
This works unless singular_values.all? { |singular_value| singular_value.point.raw? }
point_ids = singular_values.reject { _1.point.raw? }.map(&:id).to_sentence
message = "The following points are not raw: #{ point_ids }. You can only upsert " \
"live values for raw points."
return render json: { message: message }, status: :unprocessable_entity
end This doesn't unless singular_values.all? { _1.point.raw? }
point_ids = singular_values.reject { _1.point.raw? }.map(&:id).to_sentence
message = "The following points are not raw: #{ point_ids }. You can only upsert " \
"live values for raw points."
return render json: { message: message }, status: :unprocessable_entity
end producing:
Ruby 2.7 supports new syntax for block arguments, letting you access them by argument number instead of having to name them. It appears auto-instrument doesn't support this new syntax. It appears auto instrumentation trips up on blocks in 2.7 using numbered parameters. https://prathamesh.tech/2019/12/25/all-you-need-to-know-about-ruby-2-7/#numbered-parameters |
Can you let me know what version of I can't reproduce with |
parser 2.7.1.2, and ast 2.4.0 |
https://rubygems.org/gems/ast/versions/2.4.0 VERSIONS: ast 2.4.0 came out in 2018, so I don't think it understands ruby 2.7.0 https://github.com/whitequark/ast ooof, no commits in 2 years. |
I ran through versions of
|
I saw the gist, was the code then actually compiled after that? Because, then ruby says:
|
Will try that. |
We have a dependency on sorbet-rails which locks parser to >= 2.7 :P |
Yeah, the code in errors I am getting is different than the generated code in your gist My errors show a piece like:
A block is added after the all? in a weird manner. Your gist shows
Maybe I downgrade sorbet... |
We forced an upgrade in sorbet to remove ruby 2.7 warnings which caused a cascading upgrade of a bunch of other packages which then, appears to break scout. In dependency hell now. But everything seems to break if we upgrade other packages for better ruby 2.7.0 compatibility. And they force a upgrade of parser to >= 2.7 Working on it. |
I'm having no luck "going back in time", scout worked for us in the past, some point in the last few days, an upgrade occured to some package, and has broken scout's instrumentation. Still trying to narrow it down. |
@DanielJoyce I'd recommend just leaving AutoInstruments turned off until we can reconcile the behavior of parser >= 2.7.0.0. Just unset AutoInstruments is just one small part of what we capture in detailed traces. You'll still have tons of functionality without it - https://docs.scoutapm.com/#autoinstruments |
Yeah, so we are on parser 2.7.1.2 with no easy way to go back to 2.6 Here are some cases we cooked up # works
pp singular_values.all? { |_1| _1.point.raw? }
# works
pp "derp" if singular_values.all? { |_1| _1.point.nil? }
# breaks
pp "derp" if singular_values.all? { _1.point.raw? }
# breaks
pp "derp" if singular_values.all? { _1.point.type == "raw" }
# breaks
pp "derp" if singular_values.all? { _1.point.nil? } The isssue seems to be a numbered block parameter using a predicate method nested in a all? which is then used as part of a boolean check. The issue likely does exist in parser then. |
This looks sensible, maybe? |
This same thing now also breaks in my app on ruby 3.0.1, parser 3.0.1.1 and ast 2.4.2. Also this |
I'm having this issue too: looks like #401 was actually a dupe of this. |
Ruby 2.7
scout_apm (2.6.7)
Deploying to our dev env k8s instance on GCP, the pods are crashing, investigating I found the following in the logs:
Apparently this code is tripping it up:
If scount is trying to inject this code
{ ::ScoutApm::AutoInstrument("...
after the.all? { _1.point.raw? }
all block, I think it needs a newlineSomething like
The text was updated successfully, but these errors were encountered: