Show filename and line number in summary exception report #7825

New Issue

adam · 2025-12-29T20:28:43+01:00

adam commented

2025-12-29 20:28:43 +01:00

Originally created by @candlerb on GitHub (Mar 31, 2023).

NetBox version

v3.4.7

Feature type

Change to existing functionality

Proposed functionality

Currently, when there's an internal exception, Netbox shows a very minimal exception message, referring users to the forum for more info: for example

<class 'TypeError'>

ObjectVar.__init__() missing 1 required positional argument: 'model'

Python version: 3.10.6
NetBox version: 3.4.7
If further assistance is required, please post to the NetBox discussion forum on GitHub.

I propose that this should include at least the filename and line number where the exception occurred, i.e. the innermost line of backtrace.

I do not see this as a significant information leak or security issue.

Use case

People come to the forum with these errors, and in many cases it would be much quicker to help them (or for them to help themselves) if the file name and line number were known.

In particular, errors in the user's own custom scripts or reports could easily be identified as such.

Example: discussion #12111

Database changes

None

External dependencies

None

Originally created by @candlerb on GitHub (Mar 31, 2023). ### NetBox version v3.4.7 ### Feature type Change to existing functionality ### Proposed functionality Currently, when there's an internal exception, Netbox shows a very minimal exception message, referring users to the forum for more info: for example > <class 'TypeError'> > > ObjectVar.\_\_init\_\_() missing 1 required positional argument: 'model' > > Python version: 3.10.6 > NetBox version: 3.4.7 > If further assistance is required, please post to the [NetBox discussion forum](https://github.com/netbox-community/netbox/discussions) on GitHub. I propose that this should include at least the filename and line number where the exception occurred, i.e. the innermost line of backtrace. I do not see this as a significant information leak or security issue. ### Use case People come to the forum with these errors, and in many cases it would be much quicker to help them (or for them to help themselves) if the file name and line number were known. In particular, errors in the user's own custom scripts or reports could easily be identified as such. Example: discussion #12111 ### Database changes None ### External dependencies None

adam added the type: feature label 2025-12-29 20:28:43 +01:00

adam closed this issue

2025-12-29 20:28:43 +01:00

adam commented

2025-12-29 20:28:43 +01:00

@candlerb commented on GitHub (Apr 17, 2023):

Another example: #12267 would have been clearly identifiable as a bug in a plugin; ditto #13189

@candlerb commented on GitHub (Apr 17, 2023): Another example: #12267 would have been clearly identifiable as a bug in a plugin; ditto #13189

adam commented

2025-12-29 20:28:44 +01:00

@arthanson commented on GitHub (Aug 23, 2023):

Actually after looking into this I'm not sure how much value this would actually provide without a full stack trace which is a security concern. I hard-coded a division by zero error in NetBox code and with the change to show the file of the error you get:

division by zero

file: lib/python3.10/site-packages/django/core/handlers/exception.py line: 56

This is basically the last line of the stack trace which is almost always pointing to the exception library code which is not helpful. The full stack trace would contain useful info, but that would be a security concern.

It would potentially be possible to scan the stack trace lines and pick out the first one that is in NetBox code (not library code) but that could potentially be misleading.

@arthanson commented on GitHub (Aug 23, 2023): Actually after looking into this I'm not sure how much value this would actually provide without a full stack trace which is a security concern. I hard-coded a division by zero error in NetBox code and with the change to show the file of the error you get: ``` division by zero file: lib/python3.10/site-packages/django/core/handlers/exception.py line: 56 ``` This is basically the last line of the stack trace which is almost always pointing to the exception library code which is not helpful. The full stack trace would contain useful info, but that would be a security concern. It would potentially be possible to scan the stack trace lines and pick out the first one that is in NetBox code (not library code) but that could potentially be misleading.

adam commented

2025-12-29 20:28:44 +01:00

@jeremystretch commented on GitHub (Oct 13, 2023):

As there's been no further discussion, I'm going to close this out for the reasons @arthanson highlights above.

@jeremystretch commented on GitHub (Oct 13, 2023): As there's been no further discussion, I'm going to close this out for the reasons @arthanson highlights above.

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#7825