fix: debug server /tuning-history returns correct field names#429
fix: debug server /tuning-history returns correct field names#429
Conversation
The endpoint was mapping non-existent field names (r.type instead of r.tuningType, r.appliedChanges instead of r.appliedPIDChanges) and omitting verification metrics, convergence data, and log IDs entirely. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Fixes the debug server’s /tuning-history response so it exposes the correct tuning history fields (matching stored CompletedTuningRecord data) for downstream tooling consumption.
Changes:
- Corrects field mappings (e.g.,
type→tuningType) and stops returning non-existent properties. - Adds additional tuning history fields to the response (verification metrics, applied change arrays, log IDs, convergence, etc.).
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| transferFunctionMetrics: r.transferFunctionMetrics, | ||
| appliedFilterChanges: r.appliedFilterChanges, | ||
| appliedPIDChanges: r.appliedPIDChanges, | ||
| appliedFeedforwardChanges: r.appliedFeedforwardChanges, | ||
| filterLogId: r.filterLogId, | ||
| pidLogId: r.pidLogId, | ||
| verificationLogId: r.verificationLogId, | ||
| convergence: r.convergence, |
There was a problem hiding this comment.
The history record type includes additional fields that are still omitted from this debug response (e.g., quickLogId and verificationTransferFunctionMetrics). Since the PR description calls out missing log IDs / transfer-function metrics, consider including these fields (or explicitly documenting why they’re excluded) so tooling can see the full data set.
There was a problem hiding this comment.
Fixed — added quickLogId and verificationTransferFunctionMetrics in 07074b2.
| records: records.map((r: any) => ({ | ||
| id: r.id, | ||
| type: r.type, | ||
| tuningType: r.tuningType, | ||
| completedAt: r.completedAt, |
There was a problem hiding this comment.
records.map((r: any) => ...) leaves this endpoint untyped, which is how incorrect/nonexistent fields (e.g., r.type, r.appliedChanges) can slip in without compile-time errors. Consider typing records/r as CompletedTuningRecord (and the response shape) to make future field-name mismatches a TypeScript error.
There was a problem hiding this comment.
Fixed — r is now typed as CompletedTuningRecord in 07074b2.
Address CodePilot feedback: - Type `r` as CompletedTuningRecord (prevents future field-name mismatches) - Add quickLogId and verificationTransferFunctionMetrics Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Summary
/tuning-historyendpoint was mapping non-existent field names (r.typeinstead ofr.tuningType,r.appliedChangesinstead of individual change arrays)verificationMetrics: nullandtuningType: nullfor all history recordsTest plan
curl -s http://127.0.0.1:9300/tuning-history | jq '.records[0] | keys'— verify all fields presenttuningType,appliedPIDChanges,verificationPidMetrics,convergenceare populated🤖 Generated with Claude Code