Open CasperHK opened 6 days ago
If you cannot reproduce this on the demo site with the same repository or page, that commonly means this has been resolved by Gitea new stable versions. So that maybe you can try upgrade to v1.22
Please run:
SELECT *
FROM "milestone"
I'm having the exact same issue. The output of SELECT * FROM milestone;
is as follows:
id | repo_id | name | content | is_closed | num_issues | num_closed_issues | completeness | created_unix | updated_unix | deadline_unix | closed_date_unix
----+---------+-------------+---------------------------------------------------------------------------------------------+-----------+------------+-------------------+--------------+--------------+--------------+---------------+------------------
1 | 44 | CPE support | Full support for the Classic Protocol Extension: https://wiki.vg/Classic_Protocol_Extension | f | 36 | 0 | 0 | 1688473345 | 1688474665 | 253402300799 | 0
I only have one milestone. I'm on v1.22.
Then it must not be the milestone deadline, probably another timestamp on that page.
How to reproduce it?
But it is related to the milestone deadline.
You see, 253402300799
means 10000-01-01
(actually it is Fri, 31 Dec 9999 23:59:59 GMT
, then the next second is 10000-01-01
). The problem is why (and how) could you set it to a milestone and save it into database ....
Some guesses: from API? from some data migration? or some frontend behavior (JS uses millisecond)?
I guess I have a brief picture of the problem now.
In code, Gitea does use year 9999
as a special value to handle "deadline".
However, some recent frontend milestone date/time changes might break (unable to follow) this rule, maybe related to the relative-time/absolute-date component.
Maybe related to "Fix due date rendering the wrong date in issue (#26268)" and "Fix date rendering by adding <gitea-absolute-date>
(#29725)"
The deadline's date 9999-12-31 23:59:59 (local timezone)
is not able to be handled by the new code.
cc @silverwind
After reading more context, I think the real problem is the bad design of "Deadline", which uses "9999-12-31". The bad design triggers the frontend bug (say, frontend code is not right either).
A complete fix should start from refactoring the "Deadline" field of the Milestone model. A quick fix could only bypass some edge cases.
Maybe we can use 0
for the deadline_unix
in the milestone
table as no deadline. As a migration, we could replace the value which is bigger than 253402099200
as 0
in the database.
The year "9999" in web/api was introduced in year 2014 (it doesn't seem reasonable), at the moment there is no migration using such value.
And the worst thing is, when 253402300799
is stored in database, it would be read and converted again and affected by timezone, so it could become early or late values other than 9999-12-33 23:59:59
, and other logic also goes wrong.
Some more details: opening the "Edit milestone" page, the incorrect date can be seen as the due date.
The "clear" button works and clears the incorrect due date. This also resolves the frontend parse error. This sets the actual due date to 253402293599
in the database.
Maybe we can use
0
for thedeadline_unix
in themilestone
table as no deadline. As a migration, we could replace the value which is bigger than253402099200
as0
in the database.
0
should be good, but even better would be to use SQL NULL
/ JSON null
to indicate "no date" and then ensure the code that uses this value checks for null and does not attempt to blindly convert it to another timezone.
Description:
During the page change in the Milestones section, a JavaScript error is encountered that states:
This error is thrown from the file webcomponents.js at the following URL: https://10.11.20.95:3000/assets/js/webcomponents.js?v=1.21.11 at line 1,55713.
Steps to Reproduce:
Expected Behavior:
The page should change without any JavaScript errors.
Actual Behavior:
A parsing error occurs, but the milestone list is loaded correctly.
Recommendation:
Check the date formatting in the data being passed to the JavaScript function. Ensure it conforms to a valid date format that can be parsed successfully.
Note:
Open the browser console for more details on the error message and stack trace.
Gitea Version
1.21.11
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
Git Version
No response
Operating System
Ubuntu
How are you running Gitea?
The Gitea is running on Ubuntu 20.04.3 as a systemd service.
Database
MySQL/MariaDB