Activity pages (besides Pulse) seem to no longer work #30851
Comments
|
It works for me. 0f3e717 |
|
After doing the following:
I still have the problem: The x-axis appears to be correct, but I am not seeing any chart data. I also realized that I'm not seeing any contributor graphs. I'm running on a chromium-based browser. I also checked Firefox and Safari (i.e. I'm using MacOS v14.4.1) and encountered the same problem. Not sure what's going on on my end. Looking for more examples, I encountered the terraform-provider-gitea project where I also see the issue. |
|
It works for me both chrome and firefox web browser in macOS. 
|
|
No issues for me too, in light and dark themes. @kemzeb , there is no issue with your example Is there something special with your browser ? Errors in console, etc |
|
No console or network errors, I still see the the JSON responses are successful; I used Safari, Brave, and Firefox and I don't see anything. I also went on a separate Windows machine with Firefox and I still don't see any chart data. I have used both light and dark themes for each browser. |
|
I have read the PR that introduced this change and my best guess so far has to do with some problem associated to date and time handling (I'm from the US). |
|
Update: it looks like I am right. I changed my operating system to use a European date and time and I can now see the chart data. I'll see if I can make a patch for this (not a frontend wizard but I have read some of the code last night)! |
|
Alright working on this 👍 |
Before this patch, we were using `Date` getter/setter methods that worked with local time to get a list of Sundays that are in the range of some start date and end date. The problem with this was that the Sundays are in Unix epoch time and when we changed the "startDate" argument that was passed to make sure it is on a Sunday, this change would be reflected when we convert it to Unix epoch time. More specifically, I observed that we may get different Unix epochs depending on your timezone when the returned list should rather be timezone-agnostic. This led to issues in US timezones that caused the contributor, code frequency, and recent commit charts to not show any chart data. This fix resolves this by using getter/setter methods that work with UTC since it isn't dependent on timezones. Fixes #30851. --------- Co-authored-by: Sam Fisher <[email protected]>
Before this patch, we were using `Date` getter/setter methods that worked with local time to get a list of Sundays that are in the range of some start date and end date. The problem with this was that the Sundays are in Unix epoch time and when we changed the "startDate" argument that was passed to make sure it is on a Sunday, this change would be reflected when we convert it to Unix epoch time. More specifically, I observed that we may get different Unix epochs depending on your timezone when the returned list should rather be timezone-agnostic. This led to issues in US timezones that caused the contributor, code frequency, and recent commit charts to not show any chart data. This fix resolves this by using getter/setter methods that work with UTC since it isn't dependent on timezones. Fixes go-gitea#30851. --------- Co-authored-by: Sam Fisher <[email protected]>
|
will this be in |
|
We backported this patch, so it should be included in v1.22.0. I have done the following:
And haven't been able to reproduce. I went to your instance to see if I can gather any useful insights and that's where I noticed that the backend is sending negative Unix times. Here is an example I extracted from inspecting the HTTP responses: . . .
"total": {
"name": "Total",
"login": "",
"avatar_link": "",
"home_link": "",
"total_commits": 246,
"weeks": {
"-62135596800000": {
"week": -62135596800000,
"additions": 214923,
"deletions": 191599,
"commits": 246
}
}
}
. . .It doesn't make sense to be getting negative Unix times since they represent times before the Unix epoch. Given these results, I believe that this is a problem in the backend and we should maybe create a bug report for this. |
|
okay? anything I can do to help debugging rn? |
|
Side Information: I did the upgrade to 22 just 3 days ago, so I should have the bugfix already, right? So I guess, I have a weird bug in thte backend, though I would exspect server and not go binary releated |
Yes, v1.22.0 should have it.
After looking at the code that builds these Unix times, I haven't been able to determine the cause (or if the problem resides elsewhere). If you wish, you can open a new issue so that we can track this potential bug. |
I just opend up #31248 |
Description
Not sure if other users encountered this, but it appears that the contributors, contributor frequency, and recent commit graphs seem to no longer work currently i.e. I don't see any chart data.
To reproduce this, simply look at any of these pages while in a repository with recent commits.
The backend seems fine as I do see JSON responses from the related endpoints (e.g. /{username}/{repo}/activity/data for the
Contributorspage). Because of this, it looks like this maybe a problem with the frontend.I also decided to checkout 21331be (when the contributors graph was introduced) and rebuilt my dev environment. Weirdly enough I still have the same problem, so I'm not sure what's going on (maybe some direct/transitive dependency causing this break?).
Gitea Version
53b5522
Can you reproduce the bug on the Gitea demo site?
Yes
Log Gist
No response
Screenshots
No response
Git Version
git version 2.44.0
Operating System
Debian
How are you running Gitea?
In a Docker dev container firing up a Gitea dev environment using the
launch.jsonconfigurations found in Gitea's VSCode docs.I did also use try.gitea.io and looked for other user repos with chart data but they seem to have the same problem.
Database
SQLite
The text was updated successfully, but these errors were encountered: