Error messages

[stephan-buckmaster]

The app is really in good shape. One part that it struggles with is when there are errors with the upstream APIs. It places stack traces in the response, after 2 retries.

I don't think this is easy to improve, and I feel the reason is that there are too many kinds of errors.

Here is my current list:

# select distinct left(error, 180)from solid_queue_failed_executions;
                                                                                         left                                                                                         
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 {"exception_class":"Faraday::TimeoutError","message":"Net::ReadTimeout with #\u003cTCPSocket:(closed)\u003e","backtrace":["/usr/share/rvm/gems/ruby-3.2.3/gems/net-protocol-0.2.2/li
 {"exception_class":"Faraday::ResourceNotFound","message":"the server responded with status 404","backtrace":["/usr/share/rvm/gems/ruby-3.3.6/gems/faraday-2.12.1/lib/faraday/respons
 {"exception_class":"Faraday::ServerError","message":"the server responded with status 500","backtrace":["/home/user/g.rvm/gems/ruby-3.2.3/gems/faraday-2.8.1/lib/faraday/response/
 {"exception_class":"KeyError","message":"Missing configuration for the database Active Storage service. Configurations available for the test, local, and local_public services.","b
 {"exception_class":"Faraday::ConnectionFailed","message":"Failed to open TCP connection to api.openai.com:443 (getaddrinfo: Temporary failure in name resolution)","backtrace":["/us
 {"exception_class":"LoadError","message":"Could not open library 'vips.so.42': vips.so.42: cannot open shared object file: No such file or directory.\nCould not open library 'libvi
 {"exception_class":"NoMethodError","message":"undefined method `*' for nil","backtrace":["/home/user/ggit/hostedgpt/app/models/message.rb:82:in `update_input_token_cost'","/usr/s
 {"exception_class":"GetNextAIMessageJob::WaitForPrevious","message":"GetNextAIMessageJob::WaitForPrevious","backtrace":["/home/user/ghostedgpt/app/jobs/get_next_ai_message_job.rb
 {"exception_class":"TypeError","message":"String does not have #dig method","backtrace":["/home/user/ggit/hostedgpt/app/jobs/get_next_ai_message_job.rb:104:in `dig'","/home/steph
 {"exception_class":"NoMethodError","message":"undefined method `content_text=' for nil:NilClass","backtrace":["/home/user/ggit/hostedgpt/app/jobs/get_next_ai_message_job.rb:90:in
 {"exception_class":"NoMethodError","message":"undefined method `openai' for nil:NilClass","backtrace":["/home/user/ggit/hostedgpt/app/services/chat_completion_api.rb:61:in `forma
 {"exception_class":"NoMethodError","message":"undefined method `*' for nil","backtrace":["/home/user/ggit/hostedgpt/app/models/message.rb:90:in `update_output_token_cost'","/usr/
 {"exception_class":"Faraday::TooManyRequestsError","message":"the server responded with status 429","backtrace":["/usr/share/rvm/gems/ruby-3.2.3/gems/faraday-2.8.1/lib/faraday/resp

One approach would be to make a list of common errors and add them to a list to handle appropriately.

For a non-dev user this would be quite puzzling.

[krschacht]

This is a good point. I also don't have a great solution. When I encounter an error and see a stack trace, it often helps me fix it faster. Probably the best fix is to still support bubbling up more information in the event of failure, but style it so that it's not so intimidating or unreadable to a non technical user. Maybe it just pulls out the very little bit of friendly information from a stack trace and says "check the logs to see more information to diagnose this" or something like that. I'll keep this in mind and next time I encounter one of these I may just quickly restyle and submit a fix.