Skip to content
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.

Sign up for GitHub

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

Jump to bottom

No implicit conversion of Symbol into Integer #16

Open
slemrmartin opened this issue Sep 3, 2020 · 1 comment
Open

No implicit conversion of Symbol into Integer #16

slemrmartin opened this issue Sep 3, 2020 · 1 comment

Comments

@slemrmartin
Copy link

With the release 0.3.0, our apps started crashing there (looks like it's related to #12)

#<CloudWatchLogger::Client::AWS_SDK::DeliveryThread:0x000055d9d76eadf0@/usr/share/gems/gems/cloudwatchlogger-0.3.0/lib/cloudwatchlogger/client/aws_sdk/threaded.rb:49 run> terminated with exception (report_on_exception is true):
--
  | /usr/share/gems/gems/cloudwatchlogger-0.3.0/lib/cloudwatchlogger/client/aws_sdk/threaded.rb:61:in `[]': no implicit conversion of Symbol into Integer (TypeError)
  | from /usr/share/gems/gems/cloudwatchlogger-0.3.0/lib/cloudwatchlogger/client/aws_sdk/threaded.rb:61:in `block (2 levels) in initialize'
  | from /usr/share/gems/gems/cloudwatchlogger-0.3.0/lib/cloudwatchlogger/client/aws_sdk/threaded.rb:50:in `loop'
  | from /usr/share/gems/gems/cloudwatchlogger-0.3.0/lib/cloudwatchlogger/client/aws_sdk/threaded.rb:50:in `block in initialize'

Is it something new we have to set somewhere or is it a bug?

cc @coderbydesign @zshannon
@slemrmartin slemrmartin mentioned this issue Sep 3, 2020
Closed
@slemrmartin
Copy link
Author

So the problem is following:

It's expecting the logger will use only the default client.formatter method (it's converting message to hash)

we're using ManageIQ::Loggers, which is using ManageIQ::Loggers::Container::Formatter
https://github.com/ManageIQ/manageiq-loggers/blob/master/lib/manageiq/loggers/cloud_watch.rb#L27

This was referenced Sep 3, 2020
Merged
Closed
Open
coderbydesign added a commit to coderbydesign/cloudwatchlogger that referenced this issue Sep 4, 2020
@coderbydesign
Ensure backwards compatibility when default log formatter is not used
9a5fb1e 
In order for changes in zshannon#12 to not cause breakage, it assumes that the default
formatter is used, or that a custom formatter would have `epoch_time` and `message`
available on the `Hash` object.

This was surfaced by: zshannon#16

These changes leave the default formatter changes in place, but ensure that the
`timestamp` and `message` values on the log events revert to the original values
prior to zshannon#12 if the message on the queue is not a `Hash` and does not contain
`epoch_time` and `message` values. This will allow backwards compatibility and
also allow for custom formatters to still pass these values in if they wish to
benefit from the timestamp disparity.
@coderbydesign coderbydesign mentioned this issue Sep 4, 2020
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@slemrmartin