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

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?

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.

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?

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.

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?

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.

@jbauer any update on help reproducing the issue?

@robin Would probably take some more days. I checked out OneDev server and tried to run it via IntelliJ but I have some trouble configuring Maven within IntelliJ to accept self signed certificate of corporate artifactory, so IntelliJ project is red (mvn clean install in macOS terminal works though). I want to run it in debug mode and set some breakpoints.

I have taken a look into the database backup I made but I don't see anything unusual, if it is generally fine that the custom field is not linked to older issues that already exist at the time I created the custom field.

If nothing helps I clean up the database but I thought setting a break point would have been faster/easier for me.

@jbauer you may place a break point here in IDE to see if OneDev can reaches it after changing field value:

https://code.onedev.io/onedev/server/~files/4561a4b340cf8fa61e13ae2a448d0e09e5bd1cfa/server-core/src/main/java/io/onedev/server/web/component/issue/fieldvalues/FieldValuesPanel.java?position=source-172.1-172.89-1

@robin I think I found it.

The custom field I had created is called "integration" and is an enumeration that allows multiple values. One value of that field is "slack" and I have configured a Slack notification on the project as well after I had created the field. The Slack notification contains a filter "integration" is "slack" and "State" is after "accepted".

When I edit one of the old issues that do not have that custom field assigned by OneDev, the code creates an IssueChanged event that the SlackNotificationManager receives via its super class ChannelNotificationManager. The code then ends up in ChannelNotificationManager.postIfApplicable which calls the matches method. Because of the issue filter I have added to the Slack notification, this now ends up in ChoiceFieldCriteria.matches(). This methods produces a NullPointerException because it inters the allowMultiple if branch but fieldValue is null because the issue does not have the integration field assigned as it already existed before I created that custom field.

So to reproduce the issue you should:

1. Start fresh DB
2. Create project
3. Create issue A
4. Create custom field of type enumeration with allow multiple values and add a value
5. Create issue B
6. Now Issue A does not have that custom field of step 4. assigned but issue B has it assigned.
7. Create a slack notification and enter a issue filter "customField" is "value"
8. Now try to edit any field in issue A and it should fail with NullPointerException, that is somewhere swallowed and never logged. Because of the exception the IssueChanged Listener that causes the WebSocket broadcast is never called, thus the UI does not update.
9. Editing issue B should work as expected

@jbauer great insight! will fix this soon. Also will improve the code to avoid swallowing the error to make debug easier.

Thanks a lot for helping to make OneDev better.

State changed as code fixing the issue is committed (df0fa24b)

State changed as build #3540 is successful