🧪 Add test coverage for utils/metrics.ts

[anusornc]

🎯 What: Adds missing test coverage for src/utils/metrics.ts to verify the proper initialization and types of exported Prometheus metrics.
📊 Coverage: Scenarios covered include verifying the Registry export, checking that all specific metrics (like jobsSubmitted, activeAgents, messageSize, etc.) are instances of their expected Prometheus classes (Counter, Gauge, Histogram), and validating that the uptimeSeconds gauge updates automatically over time via its interval.
✨ Result: Improved test coverage and reliability for observability mechanisms, ensuring refactors or new metric additions won't silently break metric types or initialization.

---

PR created automatically by Jules for task 17555649976138862314 started by @anusornc

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[gemini-code-assist]

Code Review

This pull request introduces a new test suite in test/metrics.test.ts to verify the initialization and behavior of various Prometheus metrics, including job, agent, message, system, and legacy metrics. Feedback on the tests highlights that using real timers (setTimeout) to test the periodic update of uptimeSeconds is a flaky anti-pattern and will result in a TypeError due to the values array being initially empty. It is recommended to refactor the test suite to use Vitest's fake timers with dynamic imports and module resetting to safely and reliably test the interval behavior.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Using real timers (setTimeout for 1.5 seconds) in unit tests is a known anti-pattern that introduces flakiness and slows down the test suite. Furthermore, since the setInterval in metrics.ts only runs after 1000ms, calling (await uptimeSeconds.get()).values[0].value immediately upon test execution will throw a TypeError: Cannot read properties of undefined (reading 'value') because the values array is initially empty.

To resolve both issues, we can use Vitest's fake timers. Since the module sets up the interval immediately upon import, we can use vi.resetModules() and dynamic imports inside beforeEach to ensure the module is imported under fake timers.

  describe('uptimeSeconds update interval', () => {
    let uptimeSecondsGauge: Gauge;

    beforeEach(async () => {
      vi.useFakeTimers();
      vi.resetModules();
      const module = await import('../src/utils/metrics.js');
      uptimeSecondsGauge = module.uptimeSeconds;
    });

    afterEach(() => {
      vi.useRealTimers();
    });

    it('should update uptimeSeconds periodically', async () => {
      const initialMetrics = await uptimeSecondsGauge.get();
      expect(initialMetrics.values).toHaveLength(0);

      await vi.advanceTimersByTimeAsync(1000);

      const updatedMetrics = await uptimeSecondsGauge.get();
      expect(updatedMetrics.values).toHaveLength(1);
      expect(updatedMetrics.values[0].value).toBeGreaterThanOrEqual(1);
    });
  });