Project/Group Access Token Webhook Payloads use different date time formats for field created_at
Summary
Looking at the docs for the project and group access token events webhook, the object_attributes.created_at field differs for PAT and GAT:
- Group token:
"created_at": "2024-01-24 16:27:40 UTC" - Project token:
"created_at": "2024-02-05T03:13:44.855Z"
The MR where this was introduced shows examples in the description that have the same date time format, while the doc change in the same MR shows different formats. Which one is correct?
Steps to reproduce
I tried to receive some real production example payloads for both types, but setting key expirations to 8 days didn't trigger any event. Not sure if this is another issue or my timing expectation is just wrong. The docs make it sound like the event gets triggered 7 days before token expiration.
Example Project
none (webhooks)
What is the current bug behavior?
Date time formats for created_at differ in the same webhook event (in the docs)
What is the expected correct behavior?
Same date time formats for consistent payload processing
Relevant logs and/or screenshots
none
Output of checks
See summary for documented outputs, I failed to receive a "real" output, so omitting the "reproduced on…" label
Possible fixes
- Maybe this is just a documentation issue? As I said, couldn't get the event to trigger to test it myself (the payload examples in !141907 (merged) show the same date time format in the MR description, while the doc change in the same MR shows different formats)
- If it's not a docs issue, unify the date time format just for this webhook event if possible
- There is also #19567 which might be the cause for this and as a result unfixable (short-term)?
Whatever it is, it would be great to know which way to go, so GitLab libraries like the Go library can properly handle those events.
Thanks!
Activity
This issue was automatically tagged with the label grouppipeline execution by TanukiStan, a machine learning classification model, with a probability of 0.27.
If this label is incorrect, please tag this issue with the correct group label as well as automation:ml wrong to help TanukiStan learn from its mistakes.
If you are unsure about the correct group, please do not leave the issue without a group label. Please refer to GitLab's shared responsibility functionality guidelines for more information on how to triage this kind of issues.
Authors who do not have permission to update labels can use the
@gitlab-bot label ~"group::<correct group name>"command, or leave the issue to be triaged by group leaders initially assigned by TanukiStan.This message was generated automatically. You're welcome to improve it.
- A deleted user
added automation:ml grouppipeline execution labels
added devopsverify sectionci labels
Hey @vntw, thank you for creating this issue!
To get the right eyes on your issue more quickly, we encourage you to follow the issue triage best practices.
PLEASE NOTE: You will need to use the
@gitlab-bot label commandto apply labels to this issue.To set expectations, GitLab product managers or team members can't make any promise if they will proceed with this. However, we believe everyone can contribute, and welcome you to work on this proposed change, feature or bug fix. There is a bias for action, so you don't need to wait. Try and spin up that merge request yourself.
If you need help doing so, we're always open to mentor you to drive this change.
This message was generated automatically. You're welcome to improve it.
added automation:self-triage-encouraged label
mentioned in issue gitlab-org/quality/triage-reports#17718 (closed)
added grouppipeline security label and removed grouppipeline execution label
fyi @jocelynjane
@rutshah this might be ours because it is related to the webhooks API. But it is possibly also whichever group owns the Project/Group Access Tokens (which are different from the CI_JOB_TOKEN which grouppipeline security owns)
tagging @hsutor and @adil.farrukh for access tokens.
In the meantime, reassigning back to grouppipeline execution.
@carolinesimpson @jocelynjane Thanks! this would be with groupauthentication (the webhooks for PrAT/GrAT were adding by our team recently).
@sgarg_gitlab Could you confirm if the time format is intentionally different between Project and Group webhook APIs?
@vntw The webhook should get triggered in 7 days though we are investigating an issue (return of Users are not receiving upcoming token expirati... (#432518 - closed)) where the worker may not be triggering the notification and webhooks. Once we verify the date format, we can confirm that as well
This looks like a documentation problem. The
created_atin payload is same for group and project, I confirmed again in my local setup. I will raise an MR to fix thiscc/- @adil.farrukh
-
@vntw fyi ^^ (in case you work off mentions)
added grouppipeline execution label and removed grouppipeline security label
added groupauthentication label and removed grouppipeline execution label
removed devopsverify label
added devopsgovern label
removed sectionci label
added sectionsec label
mentioned in merge request !152907 (merged)
assigned to @sgarg_gitlab
changed milestone to %17.1
-
1 Error 
Please add typebug typefeature, typemaintenance and optionally a subtype label to this issue. If you do not feel the purpose of this issue matches one of the types, you may apply the typeignore label to exclude it from type tracking metrics and future prompts.
This message was generated automatically. You're welcome to improve it.
added Deliverable documentation typemaintenance labels
I guess its positive that the docs are now updated and in sync, but its a shame this issues wasn't taken into account: #19567
After 6 years this is still a very annoying problem when trying to property support your API in other languages (https://github.com/xanzy/go-gitlab in my case)
