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

ChangeLoggedFilterSetTests fails if TIME_ZONE setting is set #10972

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

Originally created by @alehaa on GitHub (Apr 1, 2025).

Deployment Type

Self-hosted

NetBox Version

v4.2.6

Python Version

3.11

Steps to Reproduce

  1. Define TIME_ZONE setting: 
    TIME_ZONE = "Europe/Berlin"
  2. Run a test_created test case defined by ChangeLoggedFilterSetTests: 
    > ./manage.py test dcim.tests.test_filtersets.DeviceTestCase.test_created

Expected Behavior

Test passes.

Observed Behavior

Test fails:

> ./manage.py test dcim.tests.test_filtersets.DeviceTestCase.test_created -v 1 --keepdb
...
Found 1 test(s).
Using existing test database for alias 'default'...
System check identified no issues (0 silenced).
F
======================================================================
FAIL: test_created (dcim.tests.test_filtersets.DeviceTestCase.test_created)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/opt/netbox/netbox/utilities/testing/filtersets.py", line 160, in test_created
    self.assertEqual(self.filterset(params, self.queryset).qs.count(), 2)
AssertionError: 0 != 2

----------------------------------------------------------------------
Ran 1 test in 0.082s

FAILED (failures=1)
Preserving test database for alias 'default'...
exit status 1
Originally created by @alehaa on GitHub (Apr 1, 2025). ### Deployment Type Self-hosted ### NetBox Version v4.2.6 ### Python Version 3.11 ### Steps to Reproduce 1. Define `TIME_ZONE` setting: ```Python TIME_ZONE = "Europe/Berlin" ``` 2. Run a `test_created` test case defined by `ChangeLoggedFilterSetTests`: ``` > ./manage.py test dcim.tests.test_filtersets.DeviceTestCase.test_created ``` ### Expected Behavior Test passes. ### Observed Behavior Test fails: ``` > ./manage.py test dcim.tests.test_filtersets.DeviceTestCase.test_created -v 1 --keepdb ... Found 1 test(s). Using existing test database for alias 'default'... System check identified no issues (0 silenced). F ====================================================================== FAIL: test_created (dcim.tests.test_filtersets.DeviceTestCase.test_created) ---------------------------------------------------------------------- Traceback (most recent call last): File "/opt/netbox/netbox/utilities/testing/filtersets.py", line 160, in test_created self.assertEqual(self.filterset(params, self.queryset).qs.count(), 2) AssertionError: 0 != 2 ---------------------------------------------------------------------- Ran 1 test in 0.082s FAILED (failures=1) Preserving test database for alias 'default'... exit status 1 ```
adam added the type: bug label 2025-12-29 21:38:38 +01:00
adam closed this issue 2025-12-29 21:38:38 +01:00
adam commented 2025-12-29 21:38:39 +01:00
Author
Owner
Copy Link

@alehaa commented on GitHub (Apr 1, 2025):

To fix this problem, the time zone setting can be overridden to UTC. Custom settings will then not be applied when running the tests. I volunteer to provide a PR for this.

@override_settings(TIME_ZONE='Etc/Universal')
def test_created(self):
    ...

@override_settings(TIME_ZONE='Etc/Universal')
def test_last_updated(self):
    ...
@alehaa commented on GitHub (Apr 1, 2025): To fix this problem, the time zone setting can be overridden to UTC. Custom settings will then not be applied when running the tests. I volunteer to provide a PR for this. ```Python @override_settings(TIME_ZONE='Etc/Universal') def test_created(self): ... @override_settings(TIME_ZONE='Etc/Universal') def test_last_updated(self): ... ```
adam commented 2025-12-29 21:38:40 +01:00
Author
Owner
Copy Link

@jnovinger commented on GitHub (Apr 1, 2025):

@alehaa , thanks for the bug report! I have a quick question about your steps to reproduce. Where are you setting TIME_ZONE = "Europe/Berlin"?

By default, it's not set in netbox/configuration_testing.py and so would default to 'UTC' in netbox/settings.py. If you're setting it in netbox/configuration.py, then that should not be picked up during tests.

To fix this problem, the time zone setting can be overridden to UTC. Custom settings will then not be applied when running the tests. I volunteer to provide a PR for this.

@override_settings(TIME_ZONE='Etc/Universal')
def test_created(self):
...

@override_settings(TIME_ZONE='Etc/Universal')
def test_last_updated(self):
...

I think in this case, we might be better off just setting it in configuration_testing.py or making sure that the created/last_updated times we test against use a representation that includes the TZ offset, like:

def test_created(self):
    pk_list = self.queryset.values_list('pk', flat=True)[:2]
    new_created_dt = datetime(2021, 1, 1, 0, 0, 0, tzinfo=timezone.utc)
    self.queryset.filter(pk__in=pk_list).update(created=new_created_dt)
    params = {'created': [new_created_dt.isoformat()]}
    self.assertEqual(self.filterset(params, self.queryset).qs.count(), 2)
@jnovinger commented on GitHub (Apr 1, 2025): @alehaa , thanks for the bug report! I have a quick question about your steps to reproduce. Where are you setting `TIME_ZONE = "Europe/Berlin"`? By default, it's not set in `netbox/configuration_testing.py` and so would default to `'UTC'` in [`netbox/settings.py`](https://github.com/netbox-community/netbox/blob/main/netbox/netbox/settings.py#L177). If you're setting it in `netbox/configuration.py`, then that should not be picked up during tests. > To fix this problem, the time zone setting can be overridden to UTC. Custom settings will then not be applied when running the tests. I volunteer to provide a PR for this. > > @override_settings(TIME_ZONE='Etc/Universal') > def test_created(self): > ... > > @override_settings(TIME_ZONE='Etc/Universal') > def test_last_updated(self): > ... I think in this case, we might be better off just setting it in `configuration_testing.py` or making sure that the `created`/`last_updated` times we test against use a representation that includes the TZ offset, like: ```python def test_created(self): pk_list = self.queryset.values_list('pk', flat=True)[:2] new_created_dt = datetime(2021, 1, 1, 0, 0, 0, tzinfo=timezone.utc) self.queryset.filter(pk__in=pk_list).update(created=new_created_dt) params = {'created': [new_created_dt.isoformat()]} self.assertEqual(self.filterset(params, self.queryset).qs.count(), 2) ```
adam commented 2025-12-29 21:38:40 +01:00
Author
Owner
Copy Link

@alehaa commented on GitHub (Apr 2, 2025):

Hmm. Sorry for not making that clear. The test cases using the regular netbox/configuration_testing.py work fine. However, when running the test cases in a live environment (e.g. Docker container), they may fail if the timezone is set in the regular settings. In my case it's NetBox Docker with a separate configuration file.

To make it clearer, we could turn this into a feature request. Use cases:

  • Running tests during plugin development in a custom development environment.
  • Running tests to verify that NetBox works correctly when building custom Docker images with local contributions.
@alehaa commented on GitHub (Apr 2, 2025): Hmm. Sorry for not making that clear. The test cases using the regular `netbox/configuration_testing.py` work fine. However, when running the test cases in a live environment (e.g. Docker container), they may fail if the timezone is set in the regular settings. In my case it's NetBox Docker with a separate configuration file. To make it clearer, we could turn this into a feature request. Use cases: * Running tests during plugin development in a custom development environment. * Running tests to verify that NetBox works correctly when building custom Docker images with local contributions.
adam commented 2025-12-29 21:38:40 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Apr 10, 2025):

This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.

@github-actions[bot] commented on GitHub (Apr 10, 2025): This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.
adam commented 2025-12-29 21:38:40 +01:00
Author
Owner
Copy Link

@alehaa commented on GitHub (Apr 10, 2025):

@jnovinger do you need additional information to clarify?

@alehaa commented on GitHub (Apr 10, 2025): @jnovinger do you need additional information to clarify?
adam commented 2025-12-29 21:38:41 +01:00
Author
Owner
Copy Link

@jnovinger commented on GitHub (Apr 10, 2025):

Apologies @alehaa , wanted to let you know I saw your response/question but have not had a chance to reload my context and respond. I'm heads down today, so probably won't be able to dig back in until tomorrow at the soonest--although other maintainers may have thoughts and are welcome to respond too!

@jnovinger commented on GitHub (Apr 10, 2025): Apologies @alehaa , wanted to let you know I saw your response/question but have not had a chance to reload my context and respond. I'm heads down today, so probably won't be able to dig back in until tomorrow at the soonest--although other maintainers may have thoughts and are welcome to respond too!
adam commented 2025-12-29 21:38:41 +01:00
Author
Owner
Copy Link

@bctiemann commented on GitHub (Apr 11, 2025):

My feeling is that the tests are not guaranteed to pass under normal configuration.py conditions, otherwise there would be no need for configuration_testing.py. If there's a way to make these and other tests pass using the normal config, it would mean we could get rid of the testing config altogether, but I have to imagine there are bigger reasons for having that testing config than just not being able to set the time zone properly on the time-sensitive tests.

I see that we're not using freezegun in the project anywhere; it can be very helpful in cases like this where there are time-sensitive tests, and maybe this should indeed be a feature request whose scope is to consolidate/remove the configuration_testing.py context altogether. If time-sensitive tests are the only issue it should be doable.

@bctiemann commented on GitHub (Apr 11, 2025): My feeling is that the tests are not guaranteed to pass under normal `configuration.py` conditions, otherwise there would be no need for `configuration_testing.py`. If there's a way to make these and other tests pass using the normal config, it would mean we could get rid of the testing config altogether, but I have to imagine there are bigger reasons for having that testing config than just not being able to set the time zone properly on the time-sensitive tests. I see that we're not using `freezegun` in the project anywhere; it can be very helpful in cases like this where there are time-sensitive tests, and maybe this should indeed be a feature request whose scope is to consolidate/remove the `configuration_testing.py` context altogether. If time-sensitive tests are the only issue it should be doable.
adam commented 2025-12-29 21:38:42 +01:00
Author
Owner
Copy Link

@arthanson commented on GitHub (Apr 14, 2025):

I'm going to mark this as closed as tests are only supposed to run under configuration_testing.py environment. If it is desired to change the tests to work under different time-zones for some reason then that would need to be opened as a feature request documenting why this would be needed (IMHO).

@arthanson commented on GitHub (Apr 14, 2025): I'm going to mark this as closed as tests are only supposed to run under configuration_testing.py environment. If it is desired to change the tests to work under different time-zones for some reason then that would need to be opened as a feature request documenting why this would be needed (IMHO).
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 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#10972
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?