starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Custom Script initialisation via API requests full execution history of that script for no obvious reason #10168

New Issue
Closed
opened 2025-12-29 21:27:44 +01:00 by adam · 4 comments
adam commented 2025-12-29 21:27:44 +01:00
Owner
Copy Link

Originally created by @pgnuta on GitHub (Aug 31, 2024).

Originally assigned to: @arthanson on GitHub.

Deployment Type

Self-hosted

NetBox Version

v4.0.10

Python Version

3.12

Steps to Reproduce

  1. Have 300,000+ execution history records for one particular custom script (2000+ executions per hour).
  2. Have an architecture that includes a database server not hosted on the same host as the netbox process.
  3. Initialise a new execution of that custom script via an API call.
  4. Observe that the API call HTTP response takes 20+ seconds to return.

Expected Behavior

The script execution job should be added to the background queues list faster than it is.

Observed Behavior

When the API call is first received by netbox it performs an SQL query requesting the entire execution history for that script:

2024-08-31 23:23:46.694 NZST [23469] netbox_test LOG: statement: SELECT "core_job"."id", "core_job"."object_type_id", "core_job"."object_id", "core_job"."name", "core_job"."created", "core_job"."scheduled", "core_job"."interval", "core_job"."started", "core_job"."completed", "core_job"."user_id", "core_job"."status", "core_job"."data", "core_job"."error", "core_job"."job_id" FROM "core_job" WHERE ("core_job"."object_type_id" = 69 AND "core_job"."object_id" IN (2)) ORDER BY "core_job"."created" DESC

This query takes a long time to transfer the volume of data in the table due to the size of the execution history and it waits for this to finish before the job is inserted into the table:

2024-08-31 23:24:06.992 NZST [23469] netbox_test LOG: statement: INSERT INTO "core_job" ("object_type_id", "object_id", "name", "created", "scheduled", "interval", "started", "completed", "user_id", "status", "data", "error", "job_id") VALUES (69, 2, 'SyncLibrenms', '2024-08-31 11:24:06.972273+00:00'::timestamptz, NULL, NULL, NULL, NULL, 1, 'pending', NULL, '', '7667384535e94785b75acb525133e6c5'::uuid) RETURNING "core_job"."id"

As far as i can tell there is no reason to perform this query as it is not performed when initialising a custom script execution through the frontend.

Originally created by @pgnuta on GitHub (Aug 31, 2024). Originally assigned to: @arthanson on GitHub. ### Deployment Type Self-hosted ### NetBox Version v4.0.10 ### Python Version 3.12 ### Steps to Reproduce 1. Have 300,000+ execution history records for one particular custom script (2000+ executions per hour). 2. Have an architecture that includes a database server not hosted on the same host as the netbox process. 3. Initialise a new execution of that custom script via an API call. 4. Observe that the API call HTTP response takes 20+ seconds to return. ### Expected Behavior The script execution job should be added to the background queues list faster than it is. ### Observed Behavior When the API call is first received by netbox it performs an SQL query requesting the entire execution history for that script: > 2024-08-31 23:23:46.694 NZST [23469] netbox_test LOG: statement: SELECT "core_job"."id", "core_job"."object_type_id", "core_job"."object_id", "core_job"."name", "core_job"."created", "core_job"."scheduled", "core_job"."interval", "core_job"."started", "core_job"."completed", "core_job"."user_id", "core_job"."status", "core_job"."data", "core_job"."error", "core_job"."job_id" FROM "core_job" WHERE ("core_job"."object_type_id" = 69 AND "core_job"."object_id" IN (2)) ORDER BY "core_job"."created" DESC This query takes a long time to transfer the volume of data in the table due to the size of the execution history and it waits for this to finish before the job is inserted into the table: > 2024-08-31 23:24:06.992 NZST [23469] netbox_test LOG: statement: INSERT INTO "core_job" ("object_type_id", "object_id", "name", "created", "scheduled", "interval", "started", "completed", "user_id", "status", "data", "error", "job_id") VALUES (69, 2, 'SyncLibrenms', '2024-08-31 11:24:06.972273+00:00'::timestamptz, NULL, NULL, NULL, NULL, 1, 'pending', NULL, '', '7667384535e94785b75acb525133e6c5'::uuid) RETURNING "core_job"."id" As far as i can tell there is no reason to perform this query as it is not performed when initialising a custom script execution through the frontend.
adam added the type: bugstatus: acceptedseverity: low labels 2025-12-29 21:27:44 +01:00
adam closed this issue 2025-12-29 21:27:44 +01:00
adam commented 2025-12-29 21:27:45 +01:00
Author
Owner
Copy Link

@pgnuta commented on GitHub (Aug 31, 2024):

Just a followup:

  • Yes i know that 300k+ executions in the history table is a lot, retention has been shortened from 90 days to 5 days as a workaround while we resolve this.
  • The issue is that when a lot of these scripts are fired off by external systems hitting the API at random they consume a uwsgi/gunicorn worker for 20+ seconds and the whole application grinds to a halt.
@pgnuta commented on GitHub (Aug 31, 2024): Just a followup: - Yes i know that 300k+ executions in the history table is a lot, retention has been shortened from 90 days to 5 days as a workaround while we resolve this. - The issue is that when a lot of these scripts are fired off by external systems hitting the API at random they consume a uwsgi/gunicorn worker for 20+ seconds and the whole application grinds to a halt.
adam commented 2025-12-29 21:27:45 +01:00
Author
Owner
Copy Link

@arthanson commented on GitHub (Sep 4, 2024):

@pgnuta can you please try the PR #17373 (Note: On NetBox 4.1.0) please let me know if that resolves the issue for you.

@arthanson commented on GitHub (Sep 4, 2024): @pgnuta can you please try the PR #17373 (Note: On NetBox 4.1.0) please let me know if that resolves the issue for you.
adam commented 2025-12-29 21:27:46 +01:00
Author
Owner
Copy Link

@arthanson commented on GitHub (Sep 10, 2024):

@pgnuta ?

@arthanson commented on GitHub (Sep 10, 2024): @pgnuta ?
adam commented 2025-12-29 21:27:46 +01:00
Author
Owner
Copy Link

@pgnuta commented on GitHub (Sep 11, 2024):

@arthanson. I have tested the PR and it has resolved the issue, thanks.

@pgnuta commented on GitHub (Sep 11, 2024): @arthanson. I have tested the PR and it has resolved the issue, thanks.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label severity: low status: accepted type: bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#10168
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?