Skip to content

Prepare release/3.2.6#841

Merged
symphony-enrico merged 4 commits intofinos:release/3.2.6from
symphony-enrico:prepareRelease/3.2.6
Oct 22, 2025
Merged

Prepare release/3.2.6#841
symphony-enrico merged 4 commits intofinos:release/3.2.6from
symphony-enrico:prepareRelease/3.2.6

Conversation

@symphony-enrico
Copy link
Copy Markdown
Contributor

No description provided.

symphony-enrico and others added 4 commits October 21, 2025 16:55
* Bugfix unregister activity

The ActivityRegistry is responsible for binding activities to a data feed. When an activity is registered, the system ensures that duplicates are not allowed. If an activity with the same identity is already registered, the old one is unregistered before the new one is added.
A mechanism to explicitly unregister an activity was added in a previous PR, reusing the existing logic for handling duplicate registrations. However, both the original code and the previous PR did not always behave as expected.
While this worked for Command activities, it failed for FormReplyActivity and UserJoinedRoomActivity. These activities create their listeners using lambdas, and each call produces a new lambda instance. In Java, even if two lambdas are created from the same code and the same activity instance, they are treated as different objects. Consequently, registering the same activity twice would generate a new listener object, preventing the system from detecting duplicates.
The workaround is to modify listener generation: the activity that creates the listener is now encapsulated inside the listener itself, and equals() and hashCode() are implemented so that two listeners are considered equal if they originate from the same activity. This ensures that duplicate registrations are properly detected and handled.

* Coverage improved
* Bugfix unregister activity

The ActivityRegistry is responsible for binding activities to a data feed. When an activity is registered, the system ensures that duplicates are not allowed. If an activity with the same identity is already registered, the old one is unregistered before the new one is added.
A mechanism to explicitly unregister an activity was added in a previous PR, reusing the existing logic for handling duplicate registrations. However, both the original code and the previous PR did not always behave as expected.
While this worked for Command activities, it failed for FormReplyActivity and UserJoinedRoomActivity. These activities create their listeners using lambdas, and each call produces a new lambda instance. In Java, even if two lambdas are created from the same code and the same activity instance, they are treated as different objects. Consequently, registering the same activity twice would generate a new listener object, preventing the system from detecting duplicates.
The workaround is to modify listener generation: the activity that creates the listener is now encapsulated inside the listener itself, and equals() and hashCode() are implemented so that two listeners are considered equal if they originate from the same activity. This ensures that duplicate registrations are properly detected and handled.

* Coverage improved
@linux-foundation-easycla
Copy link
Copy Markdown

CLA Not Signed

@symphony-enrico symphony-enrico merged commit cabcb19 into finos:release/3.2.6 Oct 22, 2025
0 of 3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant