Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

webhook timestamp format #14299

Closed
mmolbech opened this issue Nov 18, 2023 · 2 comments · Fixed by #14331
Closed

webhook timestamp format #14299

mmolbech opened this issue Nov 18, 2023 · 2 comments · Fixed by #14331
Assignees
Labels
severity: low Does not significantly disrupt application functionality, or a workaround is available status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application

Comments

@mmolbech
Copy link

NetBox version

v3.6.5

Python version

3.11

Steps to Reproduce

This is my first bug report :) for netbox so bear with me

I was generating a webhook feature on virtual machines - and i discovery/got annoyed on the inconstancy with the timestamp, for each event.

{"event": "updated", "timestamp": "2023-11-17 22:03:54.864187+00:00", "model": "virtualmachine", "username": "*******", "request_id": "f27dc260-7190-4494-b1a3-34754e86fe1a", "data": {"id": 60, "url": "/api/virtualization/virtual-
....

So i was looking at the code to find the place where it does the timestamping and found it in netbox/netbox/webhooks.py, and
i change line 119 in webhooks.py

from timestamp=str(timezone.now()),
to timestamp=str(timezone.now().isoformat()),

and get iso8601 format

{"event": "deleted", "timestamp": "2023-11-18T20:16:40.955375+00:00", "model": "virtualmachine", "username": "*****", "request_id": "e4fbac3e-810b-4aff-aae6-cf35c68d49a4", "data": {"id": 51, "url": "/api/virtualization/virtual-machines/51/",
.....

The other timestamps in the event is in iso8601 format

Regards
Michael

Expected Behavior

I would expect a ISO8601 format

{"event": "deleted", "timestamp": "2023-11-18T20:16:40.955375+00:00", "model": "virtualmachine", "username": "*****", "request_id": "e4fbac3e-810b-4aff-aae6-cf35c68d49a4", "data": {"id": 51, "url": "/api/virtualization/virtual-machines/51/",
.....

Observed Behavior

I saw this

{"event": "updated", "timestamp": "2023-11-17 22:03:54.864187+00:00", "model": "virtualmachine", "username": "*******", "request_id": "f27dc260-7190-4494-b1a3-34754e86fe1a", "data": {"id": 60, "url": "/api/virtualization/virtual-
....

@mmolbech mmolbech added the type: bug A confirmed report of unexpected behavior in the application label Nov 18, 2023
@abhi1693
Copy link
Member

I'm unable to understand what the inconsistency is here?

@abhi1693 abhi1693 added the status: revisions needed This issue requires additional information to be actionable label Nov 19, 2023
@mmolbech
Copy link
Author

mmolbech commented Nov 19, 2023

I have not added everything (sorry) from the output - but everywhere else you are doing iso8601 format - but also know this will break things - as people probably has made a work around
The problem is a non iso8601 format used default

"timestamp": "2023-11-21 21:00:12.324363+00:00"

and all other places the iso format is used

{
"event": "updated",
"model": "virtualmachine",
"timestamp": "2023-11-21 21:00:12.324363+00:00",
"request_id": "a9d14c77-0279-4175-a83a-b40396a8e043",
"data": {
"id": 70,
"url": "/api/virtualization/virtual-machines/70/",
"display": "Testvm",
"name": "Testvm",
"status": {
"value": "active",
"label": "Active"
},
"site": {
"id": 2,
"url": "/api/dcim/sites/2/",
},
"cluster": {
"id": 2,
"url": "/api/virtualization/clusters/2/",
"display": "TestNet",
"name": "TestNet"
},
"device": null,
"role": null,
"tenant": null,
"platform": {
"id": 4,
"url": "/api/dcim/platforms/4/",
"display": "CentOS 8 (64-bit)",
"name": "CentOS 8 (64-bit)",
"slug": "centos-8-64-bit"
},
"primary_ip": {
"id": 29,
"url": "/api/ipam/ip-addresses/29/",
"display": "100.110.65.8/22",
"family": 4,
"address": "100.110.65.8/22"
},
"primary_ip4": {
"id": 29,
"url": "/api/ipam/ip-addresses/29/",
"display": "100.110.65.8/22",
"family": 4,
"address": "100.110.65.8/22"
},
"primary_ip6": null,
"vcpus": 2.0,
"memory": 4096,
"disk": 40,
"description": "",
"comments": "",
"config_template": null,
"local_context_data": null,
"tags": [
{
"id": 7,
"url": "/api/extras/tags/7/",
"display": "NetBox-synced",
"name": "NetBox-synced",
"slug": "netbox-synced",
"color": "9e9e9e"
},
{
"id": 8,
"url": "/api/extras/tags/8/",
"color": "9e9e9e"
}
],
"custom_fields": {},
"created": "2023-11-18T22:56:06.615351+01:00",
"last_updated": "2023-11-18T23:58:29.195615+01:00",
"interface_count": 1
},
"snapshots": {
"prechange": null,
"postchange": {
"created": "2023-11-18T21:56:06.615Z",
"last_updated": "2023-11-18T22:58:29.195Z",
"description": "",
"comments": "",
"local_context_data": null,
"config_template": null,
"site": 2,
"cluster": 2,
"device": null,
"tenant": null,
"platform": 4,
"name": "Testvm",
"status": "active",
"role": null,
"primary_ip4": 29,
"primary_ip6": null,
"vcpus": "2.00",
"memory": 4096,
"disk": 40,
"interface_count": 1,
"custom_fields": {},
"tags": [
"NetBox-synced",
]
}
}
}

@arthanson arthanson self-assigned this Nov 22, 2023
@abhi1693 abhi1693 added status: accepted This issue has been accepted for implementation severity: low Does not significantly disrupt application functionality, or a workaround is available and removed status: revisions needed This issue requires additional information to be actionable labels Nov 23, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 27, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
severity: low Does not significantly disrupt application functionality, or a workaround is available status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants