ConfigContext API ignores data_path and data_file for Git data sources #774

New Issue

MrUnknownDE · 2026-04-05T17:34:24+02:00

MrUnknownDE commented

2026-04-05 17:34:24 +02:00

Originally created by @pochkaev on 12/5/2025

NetBox Edition

NetBox Community

NetBox Version

v4.4.7

Python Version

3.12

Steps to Reproduce

export NETBOX_ADDR="https://<your-netbox-host>"
export NETBOX_TOKEN="<your-token>"
export AUTH_HEADER="Authorization: Token ${NETBOX_TOKEN}"

Create a Git data source

curl -sS -X POST "${NETBOX_ADDR}/api/core/data-sources/" \
  -H "Content-Type: application/json" \
  -H "${AUTH_HEADER}" \
  -d '{
    "name": "test_datasource",
    "slug": "test-datasource",
    "type": "git",
    "source_url": "https://github.com/pochkaev/netbox_datasource.git",
    "branch": "main",
    "enabled": true,
    "sync_interval": 1440
  }'

Example response (truncated):

{
  "id": 4,
  "name": "test_datasource",
  "type": { "value": "git", "label": "Git" },
  "source_url": "https://github.com/pochkaev/netbox_datasource.git",
  "enabled": true,
  "status": { "value": "new", "label": "New" },
  "sync_interval": 1440,
  "last_synced": null
}

Assume the new data source has id = 4.

Trigger a sync so DataFiles are created

curl -sS -X POST "${NETBOX_ADDR}/api/core/data-sources/4/sync/" \
  -H "${AUTH_HEADER}"

Example response (truncated):

{
  "id": 4,
  "name": "test_datasource",
  "status": { "value": "queued", "label": "Queued" },
  "last_synced": "2025-12-05T18:19:17.719260Z"
}

Wait for the sync job to complete.

Confirm there is a DataFile for a specific JSON file
Assuming the repo contains file1.json:

curl -sS -H "${AUTH_HEADER}" \
  "${NETBOX_ADDR}/api/core/data-files/?source_id=4&path=file1.json"

Example response:

{
  "count": 1,
  "results": [
    {
      "id": 44,
      "display": "file1.json",
      "source": {
        "id": 4,
        "name": "test_datasource"
      },
      "path": "file1.json"
    }
  ]
}

So:

Data source ID: 4
Data file ID: 44
Data file path: "file1.json"

Create a Config Context with only local data (no data_source)

curl -sS -X POST "${NETBOX_ADDR}/api/extras/config-contexts/" \
  -H "Content-Type: application/json" \
  -H "${AUTH_HEADER}" \
  -d '{
    "name": "network-configcontext",
    "weight": 31,
    "is_active": true,
    "sites": [1],
    "data": {
      "net_vlans": [123]
    }
  }'

Example response (truncated):

{
  "id": 141,
  "name": "network-configcontext",
  "data_source": null,
  "data_path": "",
  "data_file": null,
  "data": { "net_vlans": [123] }
}

Verify:

curl -sS -H "${AUTH_HEADER}" \
  "${NETBOX_ADDR}/api/extras/config-contexts/141/"

Gives the same values: data_source: null, data_path: "", data_file: null.

Try to wire the context using data_source + data_path

curl -sS -X PATCH "${NETBOX_ADDR}/api/extras/config-contexts/141/" \
  -H "Content-Type: application/json" \
  -H "${AUTH_HEADER}" \
  -d '{
    "data_source": 4,
    "data_path": "file1.json"
  }'

Response (truncated):

{
  "id": 141,
  "name": "network-configcontext",
  "data_source": {
    "id": 4,
    "name": "test_datasource"
  },
  "data_path": "",
  "data_file": null,
  "data": { "net_vlans": [123] }
}

Note:

data_source is set to test_datasource.
data_path is still an empty string.
data_file is still null.

Try to wire the context using data_source + data_file

curl -sS -X PATCH "${NETBOX_ADDR}/api/extras/config-contexts/141/" \
  -H "Content-Type: application/json" \
  -H "${AUTH_HEADER}" \
  -d '{
    "data_source": 4,
    "data_file": 44
  }'

Response (truncated):

{
  "id": 141,
  "name": "network-configcontext",
  "data_source": {
    "id": 4,
    "name": "test_datasource"
  },
  "data_path": "",
  "data_file": null,
  "data": { "net_vlans": [123] }
}

Again:

data_source is set.
data_path and data_file remain unchanged.
No error is returned in either PATCH; last_updated changes, but data_path and data_file are effectively ignored.

Expected Behavior

Expected Behavior
Given that:

The web UI allows selecting both a Data source and a File when editing a Config Context.
The Git data source sync has successfully created core.DataFile objects for the repo files.
I expect that at least one of the following would work via the REST API:

Sending data_source and data_path:

PATCH /api/extras/config-contexts/141/
{
  "data_source": 4,
  "data_path": "file1.json"
}

should result in something like:

"data_source": { "id": 4, "name": "test_datasource" },
"data_path": "file1.json",
"data_file": {
  "id": 44,
  "path": "file1.json",
  ...
}

(either immediately or after the next data‑source sync).

Or, sending data_source and data_file:

PATCH /api/extras/config-contexts/141/
{
  "data_source": 4,
  "data_file": 44
}

should bind the Config Context to that DataFile (and set data_path accordingly).

In short, there should be a supported way via the REST API to do the same thing the UI does when a user picks a Git file for a Config Context.

Observed Behavior

Both PATCH requests:

Are accepted without error.
Update data_source as requested.
Leave data_path as an empty string.
Leave data_file as null.
This makes it impossible to programmatically associate an existing Config Context with a specific Git data file via the REST API, even though the UI supports this operation and the underlying core.DataFile objects exist.

*Originally created by @pochkaev on 12/5/2025* ### NetBox Edition NetBox Community ### NetBox Version v4.4.7 ### Python Version 3.12 ### Steps to Reproduce ```bash export NETBOX_ADDR="https://<your-netbox-host>" export NETBOX_TOKEN="<your-token>" export AUTH_HEADER="Authorization: Token ${NETBOX_TOKEN}" ``` 1. Create a Git data source ```bash curl -sS -X POST "${NETBOX_ADDR}/api/core/data-sources/" \ -H "Content-Type: application/json" \ -H "${AUTH_HEADER}" \ -d '{ "name": "test_datasource", "slug": "test-datasource", "type": "git", "source_url": "https://github.com/pochkaev/netbox_datasource.git", "branch": "main", "enabled": true, "sync_interval": 1440 }' ``` Example response (truncated): ```bash { "id": 4, "name": "test_datasource", "type": { "value": "git", "label": "Git" }, "source_url": "https://github.com/pochkaev/netbox_datasource.git", "enabled": true, "status": { "value": "new", "label": "New" }, "sync_interval": 1440, "last_synced": null } ``` Assume the new data source has id = 4. 2. Trigger a sync so DataFiles are created ```bash curl -sS -X POST "${NETBOX_ADDR}/api/core/data-sources/4/sync/" \ -H "${AUTH_HEADER}" ``` Example response (truncated): ```bash { "id": 4, "name": "test_datasource", "status": { "value": "queued", "label": "Queued" }, "last_synced": "2025-12-05T18:19:17.719260Z" } ``` Wait for the sync job to complete. 3. Confirm there is a DataFile for a specific JSON file Assuming the repo contains file1.json: ```bash curl -sS -H "${AUTH_HEADER}" \ "${NETBOX_ADDR}/api/core/data-files/?source_id=4&path=file1.json" ``` Example response: ```bash { "count": 1, "results": [ { "id": 44, "display": "file1.json", "source": { "id": 4, "name": "test_datasource" }, "path": "file1.json" } ] } ``` So: Data source ID: 4 Data file ID: 44 Data file path: "file1.json" 4. Create a Config Context with only local data (no data_source) ```bash curl -sS -X POST "${NETBOX_ADDR}/api/extras/config-contexts/" \ -H "Content-Type: application/json" \ -H "${AUTH_HEADER}" \ -d '{ "name": "network-configcontext", "weight": 31, "is_active": true, "sites": [1], "data": { "net_vlans": [123] } }' ``` Example response (truncated): ```bash { "id": 141, "name": "network-configcontext", "data_source": null, "data_path": "", "data_file": null, "data": { "net_vlans": [123] } } ``` Verify: ```bash curl -sS -H "${AUTH_HEADER}" \ "${NETBOX_ADDR}/api/extras/config-contexts/141/" ``` Gives the same values: data_source: null, data_path: "", data_file: null. 5. Try to wire the context using data_source + data_path ```bash curl -sS -X PATCH "${NETBOX_ADDR}/api/extras/config-contexts/141/" \ -H "Content-Type: application/json" \ -H "${AUTH_HEADER}" \ -d '{ "data_source": 4, "data_path": "file1.json" }' ``` Response (truncated): ```bash { "id": 141, "name": "network-configcontext", "data_source": { "id": 4, "name": "test_datasource" }, "data_path": "", "data_file": null, "data": { "net_vlans": [123] } } ``` Note: data_source is set to test_datasource. data_path is still an empty string. data_file is still null. 6. Try to wire the context using data_source + data_file ```bash curl -sS -X PATCH "${NETBOX_ADDR}/api/extras/config-contexts/141/" \ -H "Content-Type: application/json" \ -H "${AUTH_HEADER}" \ -d '{ "data_source": 4, "data_file": 44 }' ``` Response (truncated): ```bash { "id": 141, "name": "network-configcontext", "data_source": { "id": 4, "name": "test_datasource" }, "data_path": "", "data_file": null, "data": { "net_vlans": [123] } } ``` Again: data_source is set. data_path and data_file remain unchanged. No error is returned in either PATCH; last_updated changes, but data_path and data_file are effectively ignored. ### Expected Behavior Expected Behavior Given that: The web UI allows selecting both a Data source and a File when editing a Config Context. The Git data source sync has successfully created core.DataFile objects for the repo files. I expect that at least one of the following would work via the REST API: Sending data_source and data_path: ```bash PATCH /api/extras/config-contexts/141/ { "data_source": 4, "data_path": "file1.json" } ``` should result in something like: ```bash "data_source": { "id": 4, "name": "test_datasource" }, "data_path": "file1.json", "data_file": { "id": 44, "path": "file1.json", ... } ``` (either immediately or after the next data‑source sync). Or, sending data_source and data_file: ```bash PATCH /api/extras/config-contexts/141/ { "data_source": 4, "data_file": 44 } ``` should bind the Config Context to that DataFile (and set data_path accordingly). In short, there should be a supported way via the REST API to do the same thing the UI does when a user picks a Git file for a Config Context. ### Observed Behavior Both PATCH requests: Are accepted without error. Update data_source as requested. Leave data_path as an empty string. Leave data_file as null. This makes it impossible to programmatically associate an existing Config Context with a specific Git data file via the REST API, even though the UI supports this operation and the underlying core.DataFile objects exist.

MrUnknownDE closed this issue

2026-04-05 17:34:24 +02:00

Sign in to join this conversation.

Branches Tags

main

21455-sql-indexes-audit

21357-register-model-actions

feature

20924-plugin-ui-components

21766-improve-test-coverage-for-sortable-table-columns

21157-export-template-public-models

21025-pre-render-config-contexts

21364-swagger

feature-ip-prefix-link

20911-dropdown-3

fix_module_substitution

21160-filterset

20911-dropdown-2

20044-elevation-stuck-lightmode

7604-filter-modifiers-v3

20660-script-load

19724-graphql

14884-script

19720-macaddress-interface-generic-relation

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

No Label netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low severity: low status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug type: bug

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/netbox#774