syncv2: Add metric submission support

[russellhancox]

Part of SNT-14

[github-actions]

The latest Buf updates on your PR. Results from workflow .github/workflows/update.yml / generate (pull_request).

Build	Format	Lint	Breaking	Updated (UTC)
✅ passed	✅ passed	⏩ skipped	✅ passed	Mar 23, 2026, 3:58 AM

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds a new PublishMetrics RPC to the SantaSync protobuf API and introduces request/response messages for sending typed metrics, root labels, and a machine identifier.

Changes

Cohort / File(s)

Summary

Schema Extensions syncv2/v2.proto

Added SantaSync.PublishMetrics(PublishMetricsRequest) returns (PublishMetricsResponse) with HTTP mapping POST /metrics/{machine_id}. Introduced PublishMetricsRequest (fields: repeated Metric metrics, map<string,string> root_labels, string machine_id), nested Metric (string path, MetricKind enum, repeated Value values), nested MetricKind enum (UNKNOWN, CONSTANT, GAUGE, COUNTER), nested Value (repeated string fields, oneof metric_value { int64, bool, string, double }). Added empty PublishMetricsResponse.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

🚥 Pre-merge checks | ✅ 2

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely summarizes the main change: adding metric submission support to the syncv2 component, matching the primary addition of PublishMetrics RPC and related message structures.
Description check	✅ Passed	The description relates to the changeset by referencing SNT-14, which aligns with the PR's stated objective of adding metric submission support as part of the SNT-14 workstream, though minimal detail is provided.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch rah/snt-14-add-metrics-support-to-santa

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@syncv2/v2.proto`:
- Around line 1268-1273: The MetricKind enum must have UNKNOWN = 0 as the first
entry; update the enum declaration for MetricKind so the first value is
MetricKind_UNKNOWN = 0 and renumber the remaining entries consecutively (e.g.,
move MetricKind_UNSPECIFIED to 1 and increment MetricKind_CONSTANT,
MetricKind_GAUGE, MetricKind_COUNTER accordingly) so values remain unique and
sequential.
- Around line 57-62: The RPC definition for PublishMetrics (rpc
PublishMetrics(PublishMetricsRequest) returns (PublishMetricsResponse)) ends
with a trailing semicolon after the closing brace; remove the semicolon so the
RPC block ends with just "}" to comply with proto3 service syntax and ensure the
PublishMetrics RPC (and its http option block with post "/metrics/{machine_id}"
and body "*") parses correctly.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: dba933d1-46e8-45cb-8bd6-eb45a568b9d9

📥 Commits

Reviewing files that changed from the base of the PR and between c961c48 and 379ab9d.

📒 Files selected for processing (1)

• syncv2/v2.proto

[coderabbitai]

🧹 Nitpick comments (1)

syncv2/v2.proto (1)

1287-1290: Rename oneof fields to non-keyword identifiers.

Using int64 int64, bool bool, string string, and double double as field names is syntactically valid but fragile across proto tooling. Protobuf explicitly recommends avoiding type-name and keyword identifiers, as code generators across languages (Rust, Java, Go, etc.) may escape, rename, or trigger conflict-resolution suffixing for accessor methods—potentially breaking reflection and dynamic tooling. Use explicit names like int64_value, bool_value, string_value, double_value.

Proposed diff

       oneof metric_value {
-        int64 int64 = 2;
-        bool bool = 3;
-        string string = 4;
-        double double = 5;
+        int64 int64_value = 2;
+        bool bool_value = 3;
+        string string_value = 4;
+        double double_value = 5;
       }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@syncv2/v2.proto` around lines 1287 - 1290, The oneof fields currently named
"int64", "bool", "string", and "double" should be renamed to non-keyword
identifiers to avoid generator conflicts; update the field names to
"int64_value", "bool_value", "string_value", and "double_value" in the proto
(the message/oneof that contains the lines "int64 int64 = 2;", "bool bool = 3;",
"string string = 4;", "double double = 5;") and then update any
references/usages of those fields across the codebase or regenerate language
stubs so callers use the new accessors.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@syncv2/v2.proto`:
- Around line 1287-1290: The oneof fields currently named "int64", "bool",
"string", and "double" should be renamed to non-keyword identifiers to avoid
generator conflicts; update the field names to "int64_value", "bool_value",
"string_value", and "double_value" in the proto (the message/oneof that contains
the lines "int64 int64 = 2;", "bool bool = 3;", "string string = 4;", "double
double = 5;") and then update any references/usages of those fields across the
codebase or regenerate language stubs so callers use the new accessors.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 938dec27-8ae7-4c70-b36f-22db6aebcd35

📥 Commits

Reviewing files that changed from the base of the PR and between 642f90d and 008230f.

📒 Files selected for processing (1)

• syncv2/v2.proto