chore: added mq overview page analytics

[SagarRajput-7]

Summary

MQ Overview Page: List rendered	count
MQ Overview Page: Right Panel	attributes: {service_name, span_name, messaging_system, destination, kind_string}
MQ Overview Page: Right Drawer - graphs	add check if 6 api calls that are required is fired and returned data or not
MQ Overview Page: Right drawer navigation to trace page	filters, selectedTimeStamp

Related Issues / PR's

Screenshots

NA

Affected Areas and Manually Tested Areas

---

Important

Add analytics logging to Celery Overview page components for user interactions and data rendering.

• Analytics Logging:
  • Added logEvent calls in CeleryOverviewTable.tsx to log when the right panel is clicked and when the list is rendered.
  • Added logEvent calls in OverviewRightPanelGraph.tsx to log graph data availability and button clicks for navigating to traces.
  • Added logEvent calls in ValueInfo.tsx to log button clicks for navigating to traces with specific filters.
• Components Affected:
  • CeleryOverviewTable logs events on row click and list rendering.
  • OverviewRightPanelGraph logs events for graph data availability and trace navigation.
  • ValueInfo logs events for trace navigation with detailed filter information.

^{This description was created by for ae2e0d5. It will automatically update as commits are pushed.}

[ellipsis-dev]

❌ Changes requested. Reviewed everything up to ae2e0d5 in 2 minutes and 32 seconds

More details

• Looked at 213 lines of code in 3 files
• Skipped 0 files when reviewing.
• Skipped posting 6 drafted comments based on config settings.

1. frontend/src/pages/Celery/CeleryOverview/CeleryOverviewDetail/OverviewRightPanelGraph.tsx:133

• Draft comment:
  Ensure consistency in event naming. The logEvent here uses 'MQ Overview Page: Right Drawer - graphs' while other parts use 'Right Panel'. Align naming conventions for clarity.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50%
  While there is a naming inconsistency, this is a relatively minor issue. The logEvent name is used for analytics tracking and doesn't affect functionality. Without seeing other logEvent names in the codebase, we can't be completely certain which convention is the "correct" one. The comment suggests a change but doesn't provide strong evidence for why "Panel" is better than "Drawer".
  I might be underestimating the importance of consistent analytics naming for data analysis. Also, there could be a team-wide convention I'm not aware of.
  Even if analytics naming is important, without seeing the broader analytics naming patterns, making this change could actually introduce inconsistency with other analytics events.
  This comment should be deleted as it makes assumptions about naming conventions without strong evidence, and the change is not clearly necessary or beneficial.

2. frontend/src/pages/Celery/CeleryOverview/CeleryOverviewDetail/ValueInfo.tsx:140

• Draft comment:
  Consider centralizing the event name string (mqAnalyticsTitle) in a shared constants file to ensure consistency across components, especially when similar analytics events are logged.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50%
  While centralizing constants is generally good practice, this seems like a premature optimization. The string is only used within this component, and there's no evidence of it being used elsewhere. Moving it to a constants file would add complexity without clear benefit. The comment also doesn't point to any specific issues or inconsistencies with other analytics events.
  I could be wrong about the reuse potential - there might be other similar analytics events in other files that follow a pattern. Moving to constants could help maintain consistency across the codebase.
  Without seeing evidence of similar analytics events elsewhere or a established pattern for analytics constants, the suggestion feels speculative rather than based on a clear need.
  Delete the comment as it suggests a refactor without clear evidence of benefit or consistency issues.

3. frontend/src/components/CeleryOverview/CeleryOverviewTable/CeleryOverviewTable.tsx:461

• Draft comment:
  Ensure that spreading the entire record into the logEvent call does not inadvertently include sensitive or extraneous data. Consider filtering out or sanitizing fields before logging.
• Reason this comment was not posted:
  Marked as duplicate.

4. frontend/src/components/CeleryOverview/CeleryOverviewTable/CeleryOverviewTable.tsx:488

• Draft comment:
  Using JSON.stringify(tableData) in the dependency array may be inefficient if tableData grows large. Consider using a memoization or deep comparison hook to avoid unnecessary stringification on every render.
• Reason this comment was not posted:
  Marked as duplicate.

5. frontend/src/pages/Celery/CeleryOverview/CeleryOverviewDetail/OverviewRightPanelGraph.tsx:133

• Draft comment:
  The useEffect logging 'MQ Overview Page: Right Drawer - graphs' will fire every time any of the status values change. If the intent is to log only once after all statuses are set, consider adding a guard to prevent multiple log events.
• Reason this comment was not posted:
  Comment looked like it was already resolved.

6. frontend/src/pages/Celery/CeleryOverview/CeleryOverviewDetail/ValueInfo.tsx:117

• Draft comment:
  Consider centralizing the analytics event name (mqAnalyticsTitle) into a shared constants or configuration file to prevent duplication and potential inconsistencies across components.
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50%
  None

Workflow ID: wflow_oIkHqLybo5sxMNBr

---

Want Ellipsis to fix these issues? Tag @ellipsis-dev in a comment. You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.