Shortener not generating short url intermittently
marmarko opened this issue · 8 comments
I've been having this issue for some time and can't figure out why it could be happening.
This snippet of code fails every now and then. It's executed quite often, so I try to cache the result to avoid hitting the shortener too often. When it fails, I manually run the code in the console and it works just fine, so I'm not seeing a clear pattern here. Any ideas why the generation might be failing?
share_url = "#{Settings.protocol}#{Settings.host}/invite?url=reg/group#{group.id}/inviter#{@user.id}&fbrefresh=#{group.updated_at.to_i}#{group.id}#{@user.id}"
share_url_short = Rails.cache.fetch ["group_user_share_url_#{@user.id}#{group.id}#{group.updated_at.to_i}v3"] do
shortened_url = Shortener::ShortenedUrl.generate(share_url)
begin
"http://#{Settings.short_host}/#{shortened_url.unique_key}"
rescue Exception => e
Rails.cache.delete ["group_user_share_url#{@user.id}#{group.id}#{group.updated_at.to_i}_v3"]
Bugsnag.notify("Share URL Fail: #{share_url} #{@user.try(:id)} #{e}")
"#{Settings.protocol}#{Settings.host}/invite?url=reg/group#{group.id}"
end
end
Hi there, what type of exception is thrown? Also, what is content of the exception's stacktrace? Cheers.
Hi James,
It throws "undefined method `unique_key' for nil:NilClass", so it seems like the shortener is just returning nil from Shortener::ShortenedUrl.generate(share_url). I know that share_url is definitely not empty, as it comes back in the bugsnag noitification. An example of a failed one: https://www.vimify.com/invite?url=reg/group1806/inviter26511&fbrefresh=1446588028180626511
Do you see anything unusual with this?
Thank you!
@marmarko hi. It's probably not your case but I had a nil returned too and my issue was happening because I haven't added expires_at attribute to DB table(https://github.com/jpmcgrath/shortener#v051-to-v052). Due to https://github.com/jpmcgrath/shortener/blob/develop/app/models/shortener/shortened_url.rb#L55 it'll always return nil in case something goes wrong so you may want to check of what kind is exception in your case.
Thanks :) I already had expired_at in there. Any other ideas of what could be causing it to fail?
@marmarko, perhaps use the bang generate method (i.e. Shortener::ShortenedUrl.generate!) which will not swallow the exception when it occurs. @naive is correct that the key to working out what is happening is to find out what that exception is. Once you know the exception, can you post it here, along with the stacktrace. Cheers.
hi guys, thanks for your help. I've put in the bang version of generate and finally got the full error.
PG::InFailedSqlTransaction: ERROR: current transaction is aborted, commands ignored until end of transaction block : INSERT INTO "shortened_urls" ("url", "unique_key", "created_at", "updated_at") VALUES ($1, $2, $3, $4) RETURNING "id"
Any ideas why this would be happening? Any workarounds? Thanks!
@marmarko sorry for the delay. I've never seen that exception before and have had to do some digging: http://stackoverflow.com/questions/21138207/activerecordstatementinvalid-pg-infailedsqltransaction
The problem is that when Postgres raises an exception, it poisons future transactions on the same connection.
Unfortunately the exception info posted doesn't give us much to go on WRT to what problem postgres had. From the research I have done, it seems that it is just as likely to be an issue with your DB as with Shortener. Perhaps you could do a bit more digging and provide a full backtrace from that exception?
That said, Shortener could probably recover better from this sort of issue, so I will have a think about how best to handle this.
Thanks James!!!
On Dec 16, 2015, at 3:22 PM, James P. McGrath notifications@github.com wrote:
@marmarko https://github.com/marmarko sorry for the delay. I've never seen that exception before and have had to do some digging: http://stackoverflow.com/questions/21138207/activerecordstatementinvalid-pg-infailedsqltransaction http://stackoverflow.com/questions/21138207/activerecordstatementinvalid-pg-infailedsqltransaction
The problem is that when Postgres raises an exception, it poisons future transactions on the same connection.Unfortunately the exception info posted doesn't give us much to go on WRT to what problem postgres had. From the research I have done, it seems that it is just as likely to be an issue with your DB as with Shortener. Perhaps you could do a bit more digging and provide a full backtrace from that exception?
That said, Shortener could probably recover better from this sort of issue, so I will have a think about how best to handle this.
—
Reply to this email directly or view it on GitHub #55 (comment).