Opened 3 years ago

Closed 3 years ago

#19000 closed Bug (needsinfo)

"Share this traceback" feature leads to a site which rejects pastes

Reported by: dloewenherz Owned by: dloewenherz
Component: Core (Other) Version: 1.4
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: yes UI/UX: yes


When a site is in debug mode, the button prompting users to "Share this traceback on a public Web site" leads to a page on which rejects pastes from Django traceback pages.

I personally would opt to remove the button, but not attaching a patch until there's some sort of consensus one way or another. The one thing for sure though is that the current feature does not work as intended.

Attachments (1)

Screen Shot 2012-09-20 at 9.50.34 PM.png (151.5 KB) - added by dloewenherz 3 years ago.
Screenshot of issue

Download all attachments as: .zip

Change History (6)

comment:1 Changed 3 years ago by ptone

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to worksforme
  • Status changed from new to closed

I was just able to use the button to get a successful paste to

If you can come up with a specific traceback that is causing an error reproducibly, please open another ticket with those details.

Perhaps it was a transient issue with the server.

Changed 3 years ago by dloewenherz

Screenshot of issue

comment:2 Changed 3 years ago by dloewenherz

  • Resolution worksforme deleted
  • Status changed from closed to reopened

This bug does not have a traceback. The problem is that rejects pastes from Django traceback pages.

A screenshot of, taken less than 5 minutes ago, is attached. Reopening because this issue is valid.

comment:3 Changed 3 years ago by ptone

The feature is intended to quickly share debug information with peers on IRC or other communication channels for sites running in a non public development environment.

The rejection of tracebacks on from a live server is for reasons clearly documented in the screenshot you posted - its a feature not a bug.

The form works as expected when running the dev-server locally on a dev machine, but may not work if you have a publicly reachable staging server. Perhaps this is your case, but details are lacking.

See also: #11919 which was accepted on the basis of being able to configure a different site. So perhaps this ticket would be more accurately closed as a duplicate?

comment:4 Changed 3 years ago by dloewenherz

The thing is, this isn't from a live server. This is from my local machine. :-/

I don't know what heuristic it's using to figure out whether or not it's being referred to from a local machine, but whatever it's doing for me seems to not be working.

I suppose this is probably a dpaste issue then.

Re: #11919--I agree that this should probably be closed as a dupe. I'll get in touch with the dpaste people to see why they think my local machine is a live server.

comment:5 Changed 3 years ago by ptone

  • Resolution set to needsinfo
  • Status changed from reopened to closed

hopefully the folks can provide some information. At this point I'll close as "needsinfo" being needs info from dpaste.

If something turns up that can reasonably be used to improve the behavior from Django's end - then reopening might be warranted.

Note: See TracTickets for help on using tickets.
Back to Top