luckyframework / luckyframework/lucky
Failed to raise an exception: END_OF_STACK
- Dominant language
- Crystal
- Stars
- 2.7k
- Forks
- 172
- PR merge metrics
- No merged PRs in 30d
Description
Some kinds of dev mistakes can result in the titular error. Usually followed by a pretty nasty looking error message:
```
Failed to raise an exception: END_OF_STACK
[0x55cae972a076] *CallStack::print_backtrace:Int32 +118
[0x55cae96e3da6] __crystal_raise +86
[0x55cae96e448e] ???
[0x55cae977f6e6] *Crystal::System::File::open:Int32 +214
[0x55cae9776e7f] *File::new:File +63
[0x55cae972116d] *CallStack::read_dwarf_sections:(Array(Tuple(UInt64, UInt64, String)) | Nil) +109
[0x55cae9720efd] *CallStack::decode_line_number:Tuple(String, Int32, Int32) +45
[0x55cae97206ae] *CallStack#decode_backtrace:Array(String) +302
[0x55cae9720562] *CallStack#printable_backtrace:Array(String)+ +50
[0x55cae97899fd] *Exception+ +77
[0x55cae9789791] *Exception+ +177
[0x55cae97aaeb8] *AtExitHandlers::run:Int32 +488
[0x55cae992377b] *Crystal::main:Int32 +139
[0x55cae96eea26] main +6
[0x7fdf8fe6bb97] __libc_start_main +231
[0x55cae96ded5a] _start +42
[0x0] ???
```
This feels worse than it is when raised by Heroku because it is all you get back. If you actually run a command on the dyno itself you'll usually get a better idea of what went wrong. The two examples I can give are:
1. Trying to run `lucky db.migrate` when no `DATABASE_URL` is set in production. You get this error message before `END_OF_STACK`
```
Unhandled exception: dropdb: could not connect to database template1: could not connect to server: Connection refused
Is the server running on host "localhost" (127.0.0.1) and accepting
TCP/IP connections on port 5432?
(Exception)
```
which is easy to debug
2. When running `lucky db.drop` which isn't allowed on heroku like so: `heroku run lucky db.drop` (you're supposed to use their method `heroku pg:reset DATABASE`).
This time you don't get any message from lucky, I guess it is swallowed by Heroku and then they return the `END_OF_STACK` error I pasted from above.
Both are database related errors, so perhaps the issue is listening for errors related to db tasks?
Contributor guide
Research direction
Start by reproducing `lucky db.migrate` without `DATABASE_URL` and `heroku run lucky db.drop`, comparing the visible database error with the `END_OF_STACK` output. Trace the database task error handling and determine whether the underlying message is swallowed; done means the relevant failure remains actionable instead of ending only in `END_OF_STACK`.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- crystal, postgresql
- Domain
- backend, databases
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100