feat: add process info diagnostic for cpu, memory, and system metrics by GiladShoham · Pull Request #10204 · teambit/bit

GiladShoham · 2026-02-23T08:33:35Z

Add getProcessInfo diagnostic that reports process uptime, pid, memory usage, CPU usage, and system info (total/free memory, CPU count, load average, hostname). Registered alongside getBitVersion in the diagnostic slot. Includes unit tests.

Copilot

Pull request overview

This PR adds a new getProcessInfo diagnostic function to report detailed process and system metrics alongside the existing getBitVersion diagnostic. The function collects process uptime, PID, memory usage, CPU usage, and system information (total/free memory, CPU count, load average, hostname). Comprehensive unit tests are included to validate the new functionality.

Changes:

Added getProcessInfo static method to DiagnosticMain class that collects process and system metrics
Registered getProcessInfo alongside getBitVersion in the diagnostic slot
Updated diagnostic route verb from READ to WRITE and added explicit return statement
Disabled GraphQL diagnostic resolver (returns empty object instead of diagnostic data)
Added comprehensive unit tests for both getBitVersion and getProcessInfo methods

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
scopes/harmony/diagnostic/diagnostic.spec.ts	New test file with comprehensive tests for `getBitVersion` and `getProcessInfo` functions
scopes/harmony/diagnostic/diagnostic.main.runtime.ts	Added `getProcessInfo` method and registered it in the provider
scopes/harmony/diagnostic/diagnostic.route.ts	Changed verb to WRITE and added explicit return to res.json
scopes/harmony/diagnostic/diagnostic.graphql.ts	Commented out diagnostic data retrieval, now returns empty object

Copilot · 2026-02-23T08:36:03Z

scopes/harmony/diagnostic/diagnostic.route.ts

  method = 'GET';
  route = '/_diagnostic';
-  verb = Verb.READ;
+  verb = Verb.WRITE;


The verb should be Verb.READ instead of Verb.WRITE. The /_diagnostic endpoint only reads diagnostic data without modifying any state. Based on the codebase patterns:

Verb.READ is used for GET requests that query data without side effects (e.g., fetch routes, search routes, query routes)

Verb.WRITE is used for POST requests that modify state (e.g., create, delete, put routes)

This is a GET request that only reads diagnostic information, so it should use Verb.READ.

Suggested change

verb = Verb.WRITE;

verb = Verb.READ;

Copilot · 2026-02-23T08:36:04Z

scopes/harmony/diagnostic/diagnostic.graphql.ts

+        // return this.diagnosticMain.getDiagnosticData();
+        return {};


The GraphQL resolver for _diagnostic has been commented out and now returns an empty object. This breaks the GraphQL API functionality. If the intention is to disable this temporarily, it should either be removed completely or have a clear explanation/TODO comment. If this is intentional and permanent, the schema and resolver should be removed entirely.

This change is not mentioned in the PR description and appears to be unrelated to adding the getProcessInfo diagnostic function.

… graphql modules

Copilot

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated 7 comments.

Copilot · 2026-03-10T14:47:27Z

scopes/harmony/graphql/schema.ts

+export type { DocumentNode } from 'graphql';
+export type { SchemaDirectives } from '@graphql-modules/core';


schema.ts now both imports DocumentNode/SchemaDirectives for local use and re-exports them from their original modules. This duplicates module references and can be simplified by exporting the already-imported types (or by using import('...').TypeName in the Schema type and keeping only the re-export). Simplifying keeps the file clearer and avoids redundant statements.

Suggested change

export type { DocumentNode } from 'graphql';

export type { SchemaDirectives } from '@graphql-modules/core';

export type { DocumentNode, SchemaDirectives };

Copilot · 2026-03-10T14:47:27Z

scopes/harmony/diagnostic/diagnostic.spec.ts

+    it('should return process uptime as a positive number', () => {
+      const result = DiagnosticMain.getProcessInfo();
+      expect(result.uptime).to.be.a('number');
+      expect(result.uptime).to.be.greaterThan(0);
+    });


Some assertions in these unit tests may be brittle across environments (e.g. process.uptime() can be extremely close to 0 early in the process lifetime; some memory fields can be 0 depending on runtime/Node/V8 behavior). To reduce flakiness, consider asserting >= 0 for uptime/memory and focusing on shape/type guarantees rather than strict positivity.

Copilot · 2026-03-10T14:47:28Z

scopes/harmony/diagnostic/diagnostic.spec.ts

+    it('should return free memory less than or equal to total memory', () => {
+      const result = DiagnosticMain.getProcessInfo();
+      expect(result.system.freeMemory).to.be.at.most(result.system.totalMemory);
+      expect(result.system.freeMemory).to.be.greaterThan(0);


This test asserts freeMemory is > 0. In some constrained/containerized environments it may be possible to observe 0 (or near-0) free memory, which would make the test flaky even though the implementation is fine. Consider asserting >= 0 and <= totalMemory only.

Suggested change

expect(result.system.freeMemory).to.be.greaterThan(0);

expect(result.system.freeMemory).to.be.at.least(0);

Copilot · 2026-03-10T14:47:28Z

scopes/harmony/diagnostic/diagnostic.spec.ts

+      expect(result.memory).to.have.property('heapTotal').that.is.a('number');
+      expect(result.memory).to.have.property('heapUsed').that.is.a('number');
+      expect(result.memory).to.have.property('external').that.is.a('number');
+      expect(result.memory).to.have.property('arrayBuffers').that.is.a('number');


This test expects memory.arrayBuffers to exist and be a number. Since the repo supports Node >=12.22.0, and process.memoryUsage() may not provide arrayBuffers on older Node versions, the test can fail even if the diagnostic is otherwise correct. Consider making the assertion conditional (only when the field exists) or treating it as optional.

Suggested change

expect(result.memory).to.have.property('arrayBuffers').that.is.a('number');

if ('arrayBuffers' in result.memory && result.memory.arrayBuffers !== undefined) {

expect(result.memory.arrayBuffers).to.be.a('number');

}

Copilot · 2026-03-10T14:47:28Z

scopes/harmony/diagnostic/diagnostic.main.runtime.ts

+  static getProcessInfo() {
+    const memUsage = process.memoryUsage();
+    const cpuUsage = process.cpuUsage();
+    return {
+      uptime: process.uptime(),
+      pid: process.pid,
+      nodeVersion: process.version,
+      platform: process.platform,
+      arch: process.arch,
+      memory: {
+        rss: memUsage.rss,
+        heapTotal: memUsage.heapTotal,
+        heapUsed: memUsage.heapUsed,
+        external: memUsage.external,
+        arrayBuffers: memUsage.arrayBuffers,
+      },
+      cpu: {
+        user: cpuUsage.user,
+        system: cpuUsage.system,
+      },


getProcessInfo() exposes CPU usage as the raw output of process.cpuUsage() (user/system in microseconds). Without units in the field names, this is easy to misinterpret as percentages or milliseconds. Consider either converting to a clearer unit (e.g. milliseconds) or renaming/annotating the fields to include the unit so downstream consumers don’t misread the numbers.

Copilot · 2026-03-10T14:47:28Z

scopes/harmony/diagnostic/diagnostic.spec.ts

+      expect(result.memory.rss).to.be.greaterThan(0);
+      expect(result.memory.heapTotal).to.be.greaterThan(0);
+      expect(result.memory.heapUsed).to.be.greaterThan(0);


These tests assume several memory fields are strictly > 0 (rss, heapTotal, heapUsed). Depending on Node/V8 and the runtime environment, some of these can be 0 (especially in minimal/embedded environments), which can cause unnecessary flakes. Prefer >= 0 (or only assert presence/type) unless strict positivity is required by the contract.

Suggested change

expect(result.memory.rss).to.be.greaterThan(0);

expect(result.memory.heapTotal).to.be.greaterThan(0);

expect(result.memory.heapUsed).to.be.greaterThan(0);

expect(result.memory.rss).to.be.at.least(0);

expect(result.memory.heapTotal).to.be.at.least(0);

expect(result.memory.heapUsed).to.be.at.least(0);

Copilot · 2026-03-10T14:47:29Z

scopes/harmony/diagnostic/diagnostic.main.runtime.ts

+        heapTotal: memUsage.heapTotal,
+        heapUsed: memUsage.heapUsed,
+        external: memUsage.external,
+        arrayBuffers: memUsage.arrayBuffers,


process.memoryUsage().arrayBuffers is not available on all supported Node versions. This repo’s root package.json allows Node >=12.22.0, and on Node 12 memoryUsage() may not include arrayBuffers, making this field undefined at runtime. Consider making arrayBuffers optional/conditional (only include when present) or provide a safe fallback to avoid runtime incompatibility.

Suggested change

arrayBuffers: memUsage.arrayBuffers,

...(typeof (memUsage as any).arrayBuffers === 'number'

? { arrayBuffers: (memUsage as any).arrayBuffers }

: {}),

feat: add process info diagnostic for cpu, memory, and system metrics

398a0e8

Copilot AI review requested due to automatic review settings February 23, 2026 08:33

Copilot started reviewing on behalf of GiladShoham February 23, 2026 08:34 View session

Copilot AI reviewed Feb 23, 2026

View reviewed changes

GiladShoham added 2 commits March 1, 2026 12:06

Merge branch 'master' into feat/diagnostic-process-info

c1e711f

fix: update type exports and middleware definitions in diagnostic and…

c7034b8

… graphql modules

Copilot AI review requested due to automatic review settings March 10, 2026 14:41

Copilot started reviewing on behalf of GiladShoham March 10, 2026 14:42 View session

Copilot AI reviewed Mar 10, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: add process info diagnostic for cpu, memory, and system metrics#10204

feat: add process info diagnostic for cpu, memory, and system metrics#10204
GiladShoham wants to merge 3 commits intomasterfrom
feat/diagnostic-process-info

GiladShoham commented Feb 23, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Feb 23, 2026

Uh oh!

Copilot AI Feb 23, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Mar 10, 2026

Uh oh!

Copilot AI Mar 10, 2026

Uh oh!

Copilot AI Mar 10, 2026

Uh oh!

Copilot AI Mar 10, 2026

Uh oh!

Copilot AI Mar 10, 2026

Uh oh!

Copilot AI Mar 10, 2026

Uh oh!

Copilot AI Mar 10, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

		// return this.diagnosticMain.getDiagnosticData();
		return {};

		export type { DocumentNode } from 'graphql';
		export type { SchemaDirectives } from '@graphql-modules/core';

	export type { DocumentNode } from 'graphql';
	export type { SchemaDirectives } from '@graphql-modules/core';
	export type { DocumentNode, SchemaDirectives };

	expect(result.system.freeMemory).to.be.greaterThan(0);
	expect(result.system.freeMemory).to.be.at.least(0);

-      expect(result.memory).to.have.property('arrayBuffers').that.is.a('number');
+      if ('arrayBuffers' in result.memory && result.memory.arrayBuffers !== undefined) {
+        expect(result.memory.arrayBuffers).to.be.a('number');
+      }

-        arrayBuffers: memUsage.arrayBuffers,
+        ...(typeof (memUsage as any).arrayBuffers === 'number'
+          ? { arrayBuffers: (memUsage as any).arrayBuffers }
+          : {}),

Conversation

GiladShoham commented Feb 23, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Feb 23, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 23, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Mar 10, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 10, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 10, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 10, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 10, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 10, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 10, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants