Repository navigation
Add Alert and verify the multi-agent run and chat experience - #8
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1c18fd14a1
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if m.probe != nil { | ||
| state = m.probe(ctx, name) |
There was a problem hiding this comment.
With 16 configured services whose registered replicas consume the five-second probe deadline, this sequential loop takes about 80 seconds, making the first observations roughly 75 seconds old before the snapshot is published. Alert.poll rejects the entire response whenever any observation is older than one minute, so every snapshot in this supported configuration is discarded: actual service failures and recoveries never reach incident detection, and operators receive only a stale-monitoring incident. Bound the full sampling round, for example with concurrent probes, so published observations remain within Alert's freshness window.
Useful? React with 👍 / 👎.
Monitoring previously depended on systemd, so the normal
micro runexperience could not monitor its own services. This adds RPC health checks and a persistent Alert service, with a tested failure and recovery journey across all five agents.micro.jsonstarts Support, DevOps, Release, Monitor and Alert. Separate stores avoid file locking between processes; shared registry configuration works across them.micro runlogs when systemd units are not configured. Release starts in inspection-only mode until a workflow is configured.Validation:
go test -race ./...,go build ./...,go vet ./...and the full CLI journey passed locally. The journey starts an isolated NATS registry, runs all five agents, delegates through onemicro chat, stops and restores Support, verifies failure/recovery notifications, and restarts Alert to verify persisted delivery history. It is also included in CI.The model and webhook are local fixtures. Default mDNS, live model quality and deployment to a production host were not validated here. Repair remains manual; Monitor and Alert are single-instance services in this milestone.