Webhooks for IP addresses have wrong type of assigned_object_type in the prechange/postchange #8804

New Issue

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

adam commented

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

Originally created by @gboor on GitHub (Nov 2, 2023).

NetBox version

v3.6.4

Python version

3.11

Steps to Reproduce

Create a webhook that listens to IP address change events (or create, or delete)
Create some listener that just dumps the body of the webhook request
Create/update/delete an IP address
Inspect snapshots

Expected Behavior

I would expect the assigned_object_type to be a string, like dcim.interface.

Observed Behavior

In the snapshots, the assigned_object_type is an integer - most likely the database ID corresponding to dcim.interface.

Here is an example of a body, with most fields removed for brevity;

{
  "event": "updated",
  "model": "ipaddress",
  "data": {
    "display": "172.20.128.1/17",
    "assigned_object_type": "dcim.interface",
    "assigned_object_id": 1176
  },
  "snapshots": {
    "prechange": {
      "address": "172.20.128.1/17",
      "assigned_object_type": 27,
      "assigned_object_id": 1176
    },
    "postchange": {
      "address": "172.20.128.1/17",
      "assigned_object_type": 27,
      "assigned_object_id": 1176
    }
  }
}

As you can see, it's as expected in data, but not in snapshots.

Originally created by @gboor on GitHub (Nov 2, 2023). ### NetBox version v3.6.4 ### Python version 3.11 ### Steps to Reproduce 1. Create a webhook that listens to IP address change events (or create, or delete) 2. Create some listener that just dumps the body of the webhook request 3. Create/update/delete an IP address 4. Inspect snapshots ### Expected Behavior I would expect the `assigned_object_type` to be a string, like `dcim.interface`. ### Observed Behavior In the `snapshots`, the `assigned_object_type` is an integer - most likely the database ID corresponding to `dcim.interface`. Here is an example of a body, with most fields removed for brevity; ``` { "event": "updated", "model": "ipaddress", "data": { "display": "172.20.128.1/17", "assigned_object_type": "dcim.interface", "assigned_object_id": 1176 }, "snapshots": { "prechange": { "address": "172.20.128.1/17", "assigned_object_type": 27, "assigned_object_id": 1176 }, "postchange": { "address": "172.20.128.1/17", "assigned_object_type": 27, "assigned_object_id": 1176 } } } ``` As you can see, it's as expected in `data`, but not in `snapshots`.

adam closed this issue

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

adam commented

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

@DanSheps commented on GitHub (Nov 2, 2023):

Not sure this is so much a bug as it is just the way it works but perhaps this is something that can be improved. Going to let the other maintainers comment.

@DanSheps commented on GitHub (Nov 2, 2023): Not sure this is so much a bug as it is just the way it works but perhaps this is something that can be improved. Going to let the other maintainers comment.

adam commented

2025-12-29 20:41:29 +01:00

@gboor commented on GitHub (Nov 2, 2023):

If it's not a bug, then it's definitely unexpected behaviour. The prechange and postchange models don't match the models used in the API and data blocks.
Also 27 doesn't mean anything to me... what would I query to understand what object type that actually is?

But I'm curious what other people think. If this is how it works, I assume that that number is at least always the same across different instances of Netbox?

@gboor commented on GitHub (Nov 2, 2023): If it's not a bug, then it's definitely unexpected behaviour. The prechange and postchange models don't match the models used in the API and data blocks. Also `27` doesn't mean anything to me... what would I query to understand what object type that actually is? But I'm curious what other people think. If this is how it works, I assume that that number is at least always the same across different instances of Netbox?

adam commented

2025-12-29 20:41:29 +01:00

@jeremystretch commented on GitHub (Nov 2, 2023):

If it's not a bug, then it's definitely unexpected behaviour. The prechange and postchange models don't match the models used in the API and data blocks.

They aren't intended to. You'll notice that every other foreign key reference in a change snapshot is handled the same way. This is intentional: The snapshot is intended to compare state before and after a change, not to capture the representation of a related object, which is subject to change.

@jeremystretch commented on GitHub (Nov 2, 2023): > If it's not a bug, then it's definitely unexpected behaviour. The prechange and postchange models don't match the models used in the API and data blocks. They aren't intended to. You'll notice that every other foreign key reference in a change snapshot is handled the same way. This is intentional: The snapshot is intended to compare state before and after a change, not to capture the representation of a related object, which is subject to change.

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#8804