Prewarm function guesses errors

Jets
1

Hi, I’ve been getting errors out the prewarming function and am wondering if I am doing something wrong…not even sure if this is something that I need to worry about at this point but some anecdotal evidence tells me some of my functions may not being getting prewarmed.

Before digging too deep, I was wondering if @tung or anyone else in here may have a quick answer for me.

Any insights would be greatly appreciated. I’ve pasted in what I’m seeing in the Sentry report as well as the logs from Cloudwatch for the corresponding Sentry entry.

Here is what is geting sent off to Sentry.

  from jets/commands/call.rb:88:in `exit'
  from jets/commands/call.rb:88:in `ensure_guesses_found!'
  from jets/commands/call.rb:21:in `function_name'
  from jets/commands/call.rb:51:in `remote_run'
  from jets/commands/call.rb:29:in `run'
  from jets/preheat.rb:26:in `warm'
  from jets/preheat.rb:36:in `block (2 levels) in warm_all'

Here is what shows up in Cloudwatch.

Calling lambda function projectx-dev-alerts_controller-current_user on AWS
Function name: projectx-dev-alerts_controller-current_user
Calling lambda function projectx-dev-alert_dangers_controller-current_user on AWS
Function name: projectx-dev-alert_dangers_controller-current_user
Unable to find the function to call.
Tried: AlertDangersNotesController, Alert::DangersNotesController, Alert::Dangers::NotesController, Alert::Dangers::Notes::Controller

Unable to find the function to call.
Tried: AlertRemindersNotesController, Alert::RemindersNotesController, Alert::Reminders::NotesController, Alert::Reminders::Notes::Controller

Calling lambda function projectx-dev-alerts_controller-past on AWS
Function name: projectx-dev-alerts_controller-past
Calling lambda function projectx-dev-alerts_controller-dashboard on AWS
Function name: projectx-dev-alerts_controller-dashboard
Critical exception from handler
{
"errorMessage": "exit",
"errorType": "Function<SystemExit>",
"stackTrace": [
"/opt/ruby/gems/2.5.0/gems/jets-1.9.21/lib/jets/commands/call.rb:88:in `exit'",
"/opt/ruby/gems/2.5.0/gems/jets-1.9.21/lib/jets/commands/call.rb:88:in `ensure_guesses_found!'",
"/opt/ruby/gems/2.5.0/gems/jets-1.9.21/lib/jets/commands/call.rb:21:in `function_name'",
"/opt/ruby/gems/2.5.0/gems/jets-1.9.21/lib/jets/commands/call.rb:51:in `remote_run'",
"/opt/ruby/gems/2.5.0/gems/jets-1.9.21/lib/jets/commands/call.rb:29:in `run'",
"/opt/ruby/gems/2.5.0/gems/jets-1.9.21/lib/jets/preheat.rb:26:in `warm'",
"/opt/ruby/gems/2.5.0/gems/jets-1.9.21/lib/jets/preheat.rb:36:in `block (2 levels) in warm_all'"
]
}
Unable to find the function to call.
Tried: AssessmentScoresPrioritiesController, Assessment::ScoresPrioritiesController, Assessment::Scores::PrioritiesController, Assessment::Scores::Priorities::Controller

Calling lambda function projectx-dev-alert_dangers_controller-resolve on AWS
Function name: projectx-dev-alert_dangers_controller-resolve
Unable to find the function to call.
Tried: AlertRemindersNotesController, Alert::RemindersNotesController, Alert::Reminders::NotesController, Alert::Reminders::Notes::Controller

Calling lambda function projectx-dev-alerts_controller-active on AWS
Function name: projectx-dev-alerts_controller-active
Unable to find the function to call.
END RequestId: 54bbb6d0-2df8-4e7c-9620-37cc5ae68c46
REPORT RequestId: 54bbb6d0-2df8-4e7c-9620-37cc5ae68c46	Duration: 210.83 ms	Billed Duration: 300 ms Memory Size: 1024 MB	Max Memory Used: 132 MB	
RequestId: 54bbb6d0-2df8-4e7c-9620-37cc5ae68c46 Error: Runtime exited without providing a reason
Runtime.ExitError
2

Thanks for the info and logs.

Context and Guess

Somewhat a shot-in-the-dark guess here. Think that the lambda function names are long enough where it breaks the Jets::Call logic. The preheat logic ultimately calls Jets::Call. The jets call cli hits the same Jets::Call logic.

Whenever function names are longer than the 64 char limit, Jets detects this and elects to have CloudFormation to generate the function names instead. This was done here:

Fixed the jets call method so it is aware of longer function names. PR here:

Here’s a test:

$ jets call admin-books_controller-very_long_method_name_that_is_over_the_limit_for_pretty_function_names | jq '.statusCode'
Calling lambda function demo-dev-AdminBooksContro-VeryLongMethodNameThatIs-1PWH67DBFV89T on AWS
Function name: demo-dev-AdminBooksContro-VeryLongMethodNameThatIs-1PWH67DBFV89T
"200"
$

Released in v1.9.24

Hoping that will fix the Sentry errors you’ve been seeing.

3

Sweet, I’ve deployed thanks for looking into this…I’ll update you on the results later :slight_smile:

4

Ok, looks like, I’m still seeing the issue. I will try and dig a bit deeper this weekend. I’ll update with my progress later.

5

@tung I’ve dug a little deeper.

I have a workaround on my end ( or fix on my end depending on your point of view ).

I created a sample project for you. Please see https://github.com/balutbomber/jets-warming-example

The readme gives some details.

6

@balutbomber Thanks for putting the example repo together. It’s an issue with the Jets::Call guessing logic. Actually dug around a little bit to generate all permutations for the possible class names, but took a little too long. So instead, just added some logic that the guesser will do a simple guess first before looking up more guesses. This should fix your prewarming issues. PR here

7

Sweet, works like a charm…as always, thanks for the quick response.

1 Like