Projects onedev server Issues #1276
#1276  Specific issues are not updating the UI after saving changes to issue fields, while other issues do
Open
jbauer opened 1 week ago

That is a little weird but I have issues in OneDev that do not update the UI when editing issue field values, while other issues work as expected.

I investigated a bit and the WebSocket connection is active and the page receives KeepAlive messages from the server. However no other messages have been received after saving changes to the issue field. For issues that work as expected the WebSocket connection receives a message ObservableChanged:io.onedev.server.model.Issue:<issue number> followed by the same message being sent back from the page to the server. Then the server sends a large HTML fragment which OneDev probably uses to update the page. For the broken issues these messages were missing.

Restarting OneDev did not change anything.

So I looked into the issues and tried to find a difference. I noticed that I had introduced a new custom field of type Enumeration quite some time ago and all issues created before the creation of that custom field do not show that custom field in the list of all fields on the right side of the issue details page. All issues created after the creation of that custom field do show the field with a rendered null value Unspecified. Interestingly it seems that all issues that do not show this newly created custom field also do not update the UI when editing other custom fields. Only the issues that show this newly created custom field are updating the UI as expected.

I have no idea in which version of OneDev I have created that custom field.

jbauer commented 1 week ago

I investigated a little further and an issue that does not update the UI can be "repaired" by using batch edit and just checking the newly added custom field without giving any value. Once this has been done the newly added custom field shows up in the right sidebar with rendered null value Unspecified and then changes to the issue will update the UI via websocket.

The batch edit also produces a comment on the issue for the issue change but the table is empty, only the headers are visible:

jbauer batch edited moments ago

NamePrevious ValueCurrent Value
Robin Shen commented 1 week ago

I created an issue and added a custom field afterwards trying to reproduce the issue. However it works correctly. Are you able to reproduce the issue with a sample database?

jbauer commented 1 week ago

I created an issue and added a custom field afterwards trying to reproduce the issue. However it works correctly. Are you able to reproduce the issue with a sample database?

Did a quick try using latest docker image (your quickstart guide) and I could not reproduce it so far. However in the real installation we now have roughly 100 issues that do not update via websocket.

Looking at the issues it seems I have created that custom field sometime between 16-09-2022 and 22-09-2022 because on the first day there is one issue without that field and on the second date one issue with that field. Looking at git history of my docker compose file it seems it must have been OneDev 7.5.1 or 7.6.0 at the time I created the custom field.

However I can not reproduce it with these versions either so far.

Maybe the creation of the custom field does not trigger the issue. This was just the only difference I could spot in the UI. Maybe some OneDev upgrade caused it and then of course all older issues cause that bug while new issues won't.

I could take a look at the database if you think there might be something interesting to look at that could cause the "update UI via websocket" code to struggle.

Robin Shen commented 7 days ago

So for those 100 issues having the problem, you can get around this issue for all of them after batching edit them to add the missing custom field?

Robin Shen commented 7 days ago

Or can you copy your database to another OneDev instance, delete all irrevant data to see if you can still reproduce the issue, and then send me the backup.

jbauer commented 4 days ago

So for those 100 issues having the problem, you can get around this issue for all of them after batching edit them to add the missing custom field?

I would guess so, yes. I haven't done it yet because then the issue is gone and can not be investigated anymore. I also checked if batch edit of other things, e.g. Confidential flag, would solve the issue but it seems that only adding the custom field helps.

Or can you copy your database to another OneDev instance, delete all irrevant data to see if you can still reproduce the issue, and then send me the backup.

Does OneDev start if I duplicate the database but use an empty folder on disk? I feel a little uncomfortable with running two OneDev instances against the same folder on disk (NFS) but with separate databases and I am trying to avoid duplicating all the git projects on disk. If it will not start, would it be enough to update the o_project table and set all projects with o_codemanagement = false?

Robin Shen commented 4 days ago

For the project containing the problematic issue, you will need to create an empty folder for it, for instance: /path/to/onedev/site/projects/ (project id can be checked in project detail popup at left side of the screen).

For other projects, there is no need to create the project folder.

issue 1 of 1
Type
Bug
Priority
Normal
Assignee
Affected Versions
8.0.10
Issue Votes (0)
Watchers (4)
Reference
issue onedev/server#1276
Please wait...
Page is in error, reload to recover