Error Trace Doesn't Include Stack Trace

[stnguyen90]

Description

The documentation on Error Handling indicates there should be a stack trace, but stack traces are no longer returned.

Steps to Reproduce the Problem

1. buffalo new coke
2. cd coke
3. buffalo dev &
4. curl -H 'Content-Type: application/json' 'http://localhost:3000/does_not_exist'

Expected Behavior

trace and error should not be the same. trace should have the stack trace.

Actual Behavior

{"error":"could not find does_not_exist","trace":"could not find does_not_exist","code":404}

Info

Please run buffalo info and paste the information below where it says "PASTE_HERE".

-> Go: Checking installation
✓ The `go` executable was found on your system at: /usr/local/go/bin/go

-> Go: Checking minimum version requirements
✓ Your version of Go, 1.13.7, meets the minimum requirements.

-> Go: Checking Package Management
✓ You are using Go Modules (`go`) for package management.

-> Go: Checking PATH
✓ Your PATH contains /go/bin.

-> Node: Checking installation
✓ The `node` executable was found on your system at: /usr/bin/node

-> Node: Checking minimum version requirements
✓ Your version of Node, v10.19.0, meets the minimum requirements.

-> NPM: Checking installation
✓ The `npm` executable was found on your system at: /usr/bin/npm

-> NPM: Checking minimum version requirements
✓ Your version of NPM, 6.13.4, meets the minimum requirements.

-> Yarn: Checking installation
✓ The `yarnpkg` executable was found on your system at: /usr/bin/yarnpkg

-> Yarn: Checking minimum version requirements
✓ Your version of Yarn, 1.22.0, meets the minimum requirements.

-> PostgreSQL: Checking installation
✘ The `postgres` executable could not be found on your system.
For help setting up your Postgres environment please follow the instructions for you platform at:

https://www.postgresql.org/download/

-> MySQL: Checking installation
✘ The `mysql` executable could not be found on your system.
For help setting up your MySQL environment please follow the instructions for you platform at:

https://www.mysql.com/downloads/

-> SQLite3: Checking installation
✓ The `sqlite3` executable was found on your system at: /usr/bin/sqlite3

-> SQLite3: Checking minimum version requirements
✓ Your version of SQLite3, 3.27.2, meets the minimum requirements.

-> Cockroach: Checking installation
✘ The `cockroach` executable could not be found on your system.
For help setting up your Cockroach environment please follow the instructions for you platform at:

https://www.cockroachlabs.com/docs/stable/

-> Buffalo (CLI): Checking installation
✓ The `buffalo` executable was found on your system at: /go/bin/buffalo

-> Buffalo (CLI): Checking minimum version requirements
✓ Your version of Buffalo (CLI), v0.15.5, meets the minimum requirements.

-> Buffalo: Application Details
Pwd         /go/src/coke
Root        /go/src/coke
GoPath      /go
PackagePkg  coke
ActionsPkg  coke/actions
ModelsPkg   coke/models
GriftsPkg   coke/grifts
WithModules true
Name        coke
Bin         bin/coke
VCS         git
WithPop     true
WithSQLite  false
WithDep     false
WithWebpack true
WithNodeJs  true
WithYarn    true
WithDocker  true
WithGrifts  true
AsWeb       true
AsAPI       false
InApp       true
PackageJSON {map[build:webpack -p --progress dev:webpack --watch]}

-> Buffalo: config/buffalo-app.toml
name = "coke"
bin = "bin/coke"
vcs = "git"
with_pop = true
with_sqlite = false
with_dep = false
with_webpack = true
with_nodejs = true
with_yarn = true
with_docker = true
with_grifts = true
as_web = true
as_api = false

-> Buffalo: config/buffalo-plugins.toml
[[plugin]]
  binary = "buffalo-pop"
  go_get = "github.com/gobuffalo/buffalo-pop"

-> Buffalo: go.mod
module coke

go 1.13

require (
	github.com/cockroachdb/cockroach-go v0.0.0-20190925194419-606b3d062051 // indirect
	github.com/fatih/color v1.9.0 // indirect
	github.com/gobuffalo/buffalo v0.14.11
	github.com/gobuffalo/buffalo-pop v1.23.1
	github.com/gobuffalo/envy v1.9.0
	github.com/gobuffalo/fizz v1.9.6 // indirect
	github.com/gobuffalo/genny v0.6.0 // indirect
	github.com/gobuffalo/mw-csrf v0.0.0-20190129204204-25460a055517
	github.com/gobuffalo/mw-forcessl v0.0.0-20180802152810-73921ae7a130
	github.com/gobuffalo/mw-i18n v0.0.0-20190129204410-552713a3ebb4
	github.com/gobuffalo/mw-paramlogger v0.0.0-20190129202837-395da1998525
	github.com/gobuffalo/nulls v0.2.0 // indirect
	github.com/gobuffalo/packd v1.0.0 // indirect
	github.com/gobuffalo/packr/v2 v2.7.1
	github.com/gobuffalo/pop v4.13.1+incompatible
	github.com/gobuffalo/validate v2.0.4+incompatible // indirect
	github.com/jackc/pgconn v1.3.1 // indirect
	github.com/pkg/errors v0.9.1 // indirect
	github.com/unrolled/secure v0.0.0-20190103195806-76e6d4e9b90c
)

[graeme-verticalscope]

Looks like v1.14.3 removed the stack traces: https://gobuffalo.io/en/docs/release-notes/buffalo/v0143#removing-stack-traces-from-errors

[stnguyen90]

It's a shame it's been removed. I did find it quite helpful. Definitely not helpful now is the misleading documentation and having error and trace be the same value.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions]

This issue was closed because it has been stalled for 5 days with no activity.

[iateadonut]

This makes the framework almost unusable.

I tried to use pop relationships at the same time as buffalo-auth: gobuffalo/buffalo-auth#83 - everything was working fine for hours, as i didn't try to test buffalo-auth again until later. When I tried to signup through buffalo-auth and it no longer worked, I rooted around for hours trying to figure out what the problem was. I would have been able to figure it out pretty quickly with a stack trace.

I don't think you can expect someone to use multiple packages within the same program they are building without a stack trace in the error message.

[piti118]

This really needs to be fixed. This makes the framework essentially a pain to debug.

[sio4]

Thanks all for filing an issue and commenting.

The documentation on Error Handling indicates there should be a stack trace, but stack traces are no longer returned.

Indeed, the document is not solid and also outdated. We previously removed the feature since the stack trace does not provide meaningful information if the user application or the function making errors are not written with the consideration of tracing, but just makes the output verbose. However, we are still providing stack traces for panic cases. See the historical PRs below:

[1] #138
[2] #1643
[3] #1930
[4] #2352

However, providing a stack trace for internal errors (even if they are not a panic) could be nice, so I agree that this issue is still valid.

4. curl -H 'Content-Type: application/json' 'http://localhost:3000/does_not_exist'

But this is not the case that stack trace helps us. 404 is clear with itself, we don't need a stack trace for it. I am preparing a PR for this issue (actually as a next step of #2352) but the 4xx errors are not in scope.

Please let me know if you have ideas about it, with detailed explanations and samples if it is possible.

[sio4]

See #2361 for the current status of this feature. Briefly,

• The error page in the development mode (e.g. buffalo dev) will have a stack trace when if the errors created by the user's handler and/or the function support the %+v formatting verb (like errors created with the pkg/errors)
• The error event will have the same stack trace information for the same condition but regardless of the runtime mode