chore: Emit metric on 'onAppAddedToConversation' event WPB-21843

[bbaarriiss]

---

PR Submission Checklist for internal contributors

• The PR Title

  • conforms to the style of semantic commits messages¹ supported in Wire's Github Workflow²
  • contains a reference JIRA issue number like SQPIT-764
  • answers the question: If merged, this PR will: ... ³

• The PR Description

  • is free of optional paragraphs and you have filled the relevant parts to the best of your ability

---

What's new in this PR?

Issues

We need a custom metric to track the number of times the app is added into a conversation.

Solutions

Add the custom metric and trigger on 'onAppAddedToConversation' event received.

Testing

How to Test

Run the app. Add the Poll App user to a channel. Check the metrics via http://localhost:8080/metrics and verify that pollapp_added_to_conversation_total is visible with a count. (See sample vieq below)

[claude]

PR Review: Add metric on 'onAppAddedToConversation' event

Summary

This PR adds a custom metric to track when the Poll App is added to a conversation. The implementation is straightforward and follows existing patterns in the codebase.

Code Quality ✅

• Consistency: The implementation follows the exact same pattern as existing metrics (onHelpCommand, onCreatePollCommand)
• Naming: Metric name pollapp_added_to_conversation_total is consistent with the naming convention (pollapp_*_total)
• Code placement: The metric is correctly placed at line 29 in MessagesHandlingService.kt, right before the welcome message is sent
• Clean code: Simple, focused changes with no unnecessary complexity

Potential Issues ⚠️

1. Missing test coverage: The PR does not include a test for handleAppAddedToConversation() to verify that usageMetrics.onAppAddedToConversation() is called
   • File: src/test/kotlin/com/wire/apps/polls/services/MessagesHandlingServiceTest.kt
   • Recommendation: Add a test similar to the existing ones (e.g., lines 77-89 for help command) to verify the metric is incremented when the app is added to a conversation

Performance Considerations ✅

• No concerns: Counter increment is a lightweight operation
• Micrometer Counter: Uses the correct Micrometer Counter which is thread-safe and designed for high-throughput scenarios

Security Concerns ✅

• No security issues identified: The change only adds metric tracking, no external inputs or data exposure

Test Coverage ⚠️

Recommendation: Add a test case to verify the new metric is being tracked:

@Test
fun `handleAppAddedToConversation calls onAppAddedToConversation metric`() =
    runTest {
        // arrange
        val conversationId = Stub.conversationId()

        // act
        messagesHandlingService.handleAppAddedToConversation(manager, conversationId)

        // assert
        coVerify(exactly = 1) { usageMetrics.onAppAddedToConversation() }
        coVerify(exactly = 1) { userCommunicationService.sayHello(any(), any()) }
    }

This would bring the test coverage in line with the other metrics in the codebase (see lines 77-89 for onHelpCommand test pattern).

Overall Assessment

Approved with minor recommendation ✅

The implementation is solid and follows established patterns. The only improvement would be adding a test case for completeness. The change is low-risk and provides valuable telemetry data.

[spoonman01]

Good, don't know if Claude suggestion to add a test makes sense or not, leave it to you

[bbaarriiss]

@spoonman01 Claude is right, I should add at least a happy path test here. Now added. Thanks for noting.

[claude]

PR Review: Add metric for app added to conversation

Summary

This PR adds a custom metric pollapp_added_to_conversation_total to track when the Poll App is added to conversations. The implementation is clean and follows existing patterns in the codebase.

✅ Code Quality & Best Practices

Strengths:

• Consistent with existing patterns: The new metric follows the exact same pattern as helpCommandCounter and createPollCommandCounter in UsageMetrics.kt
• Proper naming convention: The metric name pollapp_added_to_conversation_total follows the existing naming scheme (prefix + description + _total)
• Clear description: The metric description is concise and accurately describes what is being tracked
• Proper placement: The metric call is correctly placed at the beginning of handleAppAddedToConversation() in MessagesHandlingService.kt:29
• Good test coverage: The new test verifies both the metric increment and the expected behavior (sayHello call)

Code Style:

• Kotlin code style is consistent with the rest of the codebase
• Test naming follows the existing convention (backtick descriptions)
• Proper use of MockK verification patterns

🔍 Potential Issues

None identified - The implementation is straightforward and correct.

⚡ Performance Considerations

No concerns:

• Counter increment operations in Micrometer are highly optimized and thread-safe
• The metric call adds negligible overhead to the handleAppAddedToConversation() method
• No synchronous I/O or blocking operations introduced

🔒 Security Concerns

No security issues identified:

• The change only adds observability through metrics
• No user data or sensitive information is exposed in the metric
• The counter only tracks the number of events, not any conversation-specific data

🧪 Test Coverage

Good test coverage:

• ✅ New test added: handleAppAddedToConversation method call triggers needed method calls (line 174-180)
• ✅ Test verifies the metric is incremented exactly once
• ✅ Test verifies the expected side effect (sayHello is called)
• ✅ Uses the existing test infrastructure and mocking patterns

Suggestion for future consideration:
While not blocking for this PR, you might consider adding integration tests that verify the actual metric value is exposed via the /metrics endpoint, similar to what's described in the "How to Test" section of the PR description.

📝 Minor Observations

1. Test variable declaration (line 23): The test uses val for mock declarations which is appropriate. However, notice that these are declared at class level rather than in a @BeforeEach setup. This is consistent with the existing test style in this file.

2. Metric registration pattern: All metrics are eagerly registered during UsageMetrics instantiation, which is the correct approach for Micrometer.

✨ Final Verdict

LGTM! 🚀

This is a clean, well-tested addition that follows the established patterns in the codebase. The implementation is production-ready and aligns with the stated goal of tracking app adoption metrics.

Recommendations:

• ✅ Safe to merge
• No blocking issues identified
• Consider documenting available metrics in a central location (e.g., README or docs) as the number of metrics grows

Great work on including the test and following the existing code patterns!