TypeError: no implicit conversion of Hash into String

[gregoryfm]

First, thank you for this gem.

I'm trying to use the view changes in a time range:
PaperTrailScrapbook::UserJournal.new(who, start: "2021-03-15".to_datetime.beginning_of_day, end: "2021-03-19".to_datetime.end_of_day).story

But it gives this error:
TypeError: no implicit conversion of Hash into String

Thanks.

[dinjas]

Hi @gregoryfm - thanks for the issue.

Your syntax appears to be correct and I haven't been able to reproduce your issue.

What version of the gem are you using? What versions of Ruby/Rails/PaperTrail?

Do you get a stacktrace that you can provide when you get the TypeError?

[gregoryfm]

Hi @dinjas

Ruby: 2.5.3
Rails: 5.1.6
Paper Trail: 10.3.1

Stacktrace:

[2] pry(main)> PaperTrailScrapbook::UserJournal.new(who, start: "2021-03-15".to_datetime.beginning_of_day, end: "2021-03-19".to_datetime.end_of_day).story

PaperTrail::Version Load (2538.9ms)  SELECT "versions".* FROM "versions" WHERE "versions"."whodunnit" = $1 AND ("versions"."created_at" BETWEEN $2 AND $3)  [["whodunnit", "1"], ["created_at", "2021-03-15 00:00:00"], ["created_at", "2021-03-19 23:59:59.999999"]]

TypeError: no implicit conversion of Hash into String
from /Users/dev/.rvm/rubies/ruby-2.5.3/lib/ruby/2.5.0/psych.rb:402:in `parse'

[tjchambers]

In my experience this is most likely a parser issue where the data like "" is treated as an empty hash by a YAML parser. Here is my suggestion assuming you can look at your results.

• issue the SQL query and capture the results. Examine them for cases where the before or after values are recorded as empty string (aka '' or "") those are probably being treated as Hash when parsing the object or object_changes
• Try a different subset of data to see if it is data dependent. This can be difficult if all the data has these constructs. So changing the who or time range may still end up with same outcome.
• Share the data if possible with us (minimal subset) so we can examine it in light of how the gem processes it.

Bottomline is it may be data specific and if we could confirm that, then it may be possible to avoid the issue as a special case. Without looking at the data that results it would be difficult to say for certain.