Repository navigation
Restore the current Coroot observation window #5784
Description
🤖 Generated by the Agentic Engineer
Description
The read-only health observer sends seconds for Coroot's absolute time parameters. The pinned Coroot release interprets these parameters as milliseconds, so a current one-hour request addresses a short interval in 1970 and cannot establish current application health. This blocks diagnosis and recovery verification.
Steps to Reproduce
- Inspect the requests made by the observer at a fixed current clock.
- Interpret their absolute
fromandtovalues with the pinned Coroot parser's milliseconds convention. - Compare the server's interpreted interval with the observer's reported one-hour window.
Expected Behavior
Application, risk and alert requests address the same current one-hour interval. Incomplete or invalid responses still report UNVERIFIED.
Actual Behavior
The requests serialize seconds. The first reviewed observation failed closed at application-overview with exit 2; no Coroot health verdict was produced.
Environment
The Coroot source pin is 15137ef2f43e01d0a87245e44b937b25515e0afe (v1.28.1). Its absolute-time parser divides integer inputs by 1,000.
Acceptance Criteria
- A regression fails for seconds and passes for Coroot-compatible absolute timestamps on all three query surfaces.
- The requested interval matches the snapshot's UTC one-hour window, including subsecond boundaries.
- Existing incomplete-response, output privacy, dispatch and target restrictions remain enforced.
- After protected delivery, a separately confirmed first-attempt observation at the corrected revision is collected; incomplete runtime evidence remains explicitly unverified.
Metadata
Metadata
Assignees
Labels
Type
Fields
Priority
Effort
Projects
- Status
Activity
coderabbitai commentedon Nov 2, 2026
🔗 Related PRs
#5755 - feat(observability): add a read-only runtime health snapshot [closed]
📝 Issue Planner
Check the box below or use the
@coderabbitai plancommand to generate an implementation plan and prompts that you can use with your favorite coding assistant.🧪 Issue enrichment is currently in open beta.
You can configure auto-planning by selecting labels in the issue_enrichment configuration.
To disable automatic issue enrichment, add the following to your
.coderabbit.yaml:💬 Have feedback or questions? Drop into our discord!
chore: agent-claim #5784 nonce=34c96c0622231facb0b6afee81701e44
chore: agent-claim #5784 nonce=c9911069c139762348ced7309d632fcd
devantler commentedon Nov 2, 2026
This is a rung-0 repair of the owned main diagnostic that failed in run 41520671964. It is admitted under the immediate hotfix rule, with an incident-specific WIP exception; it does not establish spare capacity for unrelated work. The original failure, protected delivery and follow-up observation remain part of the same recovery work.
The regression reproduced the January 1970 request on all three query surfaces. A second control caught a mismatch between reported subsecond boundaries and Coroot's whole-second interpretation. The corrected current-head package passes race tests and vet. The compiled old command still fails at application-overview against the controlled API fixture, while the corrected command completes all six reads and preserves nonzero issues, log errors, alerts and risks. This is client protocol proof; live Coroot recovery remains unverified until protected delivery and readback.
chore: agent-claim #5784 nonce=b20d4c6d681d354a4078faee63cfc3a1
chore: agent-claim #5784 nonce=3f1607c1034d5a293f184a92dff10355
chore: agent-claim #5784 nonce=0af0297ed2f7c7090d25459a8aafc193
devantler commentedon Nov 3, 2026
Protected delivery is verified: #5786 merged as
67c1eb4da03b736834144d250087ede59a8ea655. After confirming the millisecond query fix in current main, I dispatched the existing read-only observer once. Run 41596956783, attempt 1 atc07c9292da6966730e3b135a2541f4e22b3aec47, succeeded and read the actual 06:32:32–07:32:32 UTC window on 3 November.The observer completed all three Coroot query surfaces and retained nonzero findings: ten application log-error patterns, six unresolved alerts and two non-dismissed risks. It also observed no installed runtime-rule/binding objects and explicitly returned
full_platform_acceptance_verified:false. This establishes the observer repair and its post-delivery readback, not a platform all-clear. The earlier failed revision was not redispatched.