event
Read ../idmp-shared/SKILL.md first.
Before any write: Follow the 🛑 Destructive op confirmation protocol. Read-only commands stay read-only here, but delete / write / patch flows still require the shared yes-gate.
Recommended shortcuts
| Shortcut |
Purpose |
+list |
List events with paging and element filters. |
+search |
Search events globally. |
+count |
Read the count of unacknowledged events. |
+get |
Read one event in detail. |
Recommended references
Missing context to resolve first
| Context |
Why it must be resolved before mutation |
| Failure boundary |
Decide whether you are debugging missing event generation, missing delivery, or both. |
| Event scope |
You need an eventId, an analysisId, or a narrow enough search scope to avoid acting on the wrong event. |
| Operator intent |
Confirm whether acknowledgement, resend, or annotation is actually allowed in this session. |
| Verification window |
Decide which reread window and filters will prove the event was found, acknowledged, or retried. |
Constrained live behaviors
status=Unack alone is not always reliable in shared environments; when you already know the producer analysis, reread events with analysisId before deciding the event is missing.- Capture event detail and context before you run
confirm or resend; both commands have operator-visible side effects.
resend retries delivery only. It does not acknowledge or recreate the event.- A successful
resend does not guarantee a fresh top-level notification-history row. Delivery history is detail-based, can lag, and can be throttled by the event's minimum notification interval.
- Shared environments can surface stale events whose
event events items call fails because the linked analysis was already deleted; try a fresher event before assuming the CLI path is wrong.
- Create alert rules from
../idmp-workflow-alert-create/SKILL.md, not from this event read workflow.
Product behavior to preserve
- Start with the unacknowledged-event path: count, list/search, detail, context, confirm or resend, then annotations.
- Treat confirm and batch confirm as the real acknowledgement workflow.
- Use
items to inspect event context before retrying notifications.
- Use
annotations to keep operator notes with the event.
- Create alert rules from alert workflows, not from the event read workflow.
Key commands
idmp-cli schema event.count.list
idmp-cli event count list
idmp-cli schema event.events.list
idmp-cli event events list --params '{"current":1,"size":20}'
idmp-cli event events search --params '{"keyword":"overcurrent","current":1,"size":20}'
idmp-cli event events get --params '{"eventId":123}'
idmp-cli event events items --params '{"eventId":123}'
idmp-cli event events confirm --ack-risk --params '{"eventId":123}'
idmp-cli event events confirm --dry-run --ack-risk --params '{"eventId":123}'
idmp-cli event confirm create --ack-risk --data '[123,456]'
idmp-cli event confirm create --dry-run --ack-risk --data '[123,456]'
idmp-cli event events resend --dry-run --ack-risk --params '{"eventId":123}'
idmp-cli event annotations list --params '{"eventId":123}'
Exception and failure handling
- If an event disappears from the unacknowledged view after confirm, treat that as expected acknowledgement behavior rather than data loss.
- If
resend succeeds, expect notification delivery to retry only; it does not acknowledge or rewrite the event.
- If
resend succeeds but no fresh history row appears, widen the notification-history reread and consider notification throttling before assuming the retry did nothing.
- If
items or annotations is empty, continue with event detail and notification checks instead of repeating confirm/resend blindly.
- If confirm or resend fails, stop retrying and inspect detail, context, and notification history before the next action.
- If list results look noisy, narrow the workflow with count, search, and detail rather than acknowledging from a broad page.
Validation scenarios
- Start the unacknowledged workflow with
idmp-cli schema event.count.list and idmp-cli event count list.
- Read the current queue with
idmp-cli event events list --params '{"current":1,"size":20}' and idmp-cli event events search --params '{"keyword":"overcurrent","current":1,"size":20}'.
- Inspect one event with
idmp-cli event events get --params '{"eventId":123}' and idmp-cli event events items --params '{"eventId":123}'.
- Acknowledge a single event with
idmp-cli event events confirm --ack-risk --params '{"eventId":123}', then run batch acknowledgement with idmp-cli event confirm create --ack-risk --data '[123,456]' or preview it first with --dry-run.
- Preview follow-up actions with
idmp-cli event events resend --dry-run --ack-risk --params '{"eventId":123}' and idmp-cli event annotations list --params '{"eventId":123}'.
1---2name: idmp-event3description: IDMP event skill for listing, searching, confirming, resending, annotating, and reading event context through the real unacknowledged-event workflow.4---56# event78**Read [`../idmp-shared/SKILL.md`](../idmp-shared/SKILL.md) first.**910**Before any write:** Follow the [🛑 Destructive op confirmation protocol](../idmp-shared/SKILL.md#-destructive-op-confirmation-mandatory). Read-only commands stay read-only here, but delete / write / patch flows still require the shared yes-gate.111213## Recommended shortcuts1415| Shortcut | Purpose |16|----------|---------|17| `+list` | List events with paging and element filters. |18| `+search` | Search events globally. |19| `+count` | Read the count of unacknowledged events. |20| `+get` | Read one event in detail. |2122## Recommended references2324- [`event read flows`](references/event-read-flows.md)25- [`../idmp-workflow-alert-create/SKILL.md`](../idmp-workflow-alert-create/SKILL.md)26- [`../idmp-workflow-alert-debug/SKILL.md`](../idmp-workflow-alert-debug/SKILL.md)2728## Missing context to resolve first2930| Context | Why it must be resolved before mutation |31| --- | --- |32| Failure boundary | Decide whether you are debugging missing event generation, missing delivery, or both. |33| Event scope | You need an `eventId`, an `analysisId`, or a narrow enough search scope to avoid acting on the wrong event. |34| Operator intent | Confirm whether acknowledgement, resend, or annotation is actually allowed in this session. |35| Verification window | Decide which reread window and filters will prove the event was found, acknowledged, or retried. |3637## Constrained live behaviors3839- `status=Unack` alone is not always reliable in shared environments; when you already know the producer analysis, reread events with `analysisId` before deciding the event is missing.40- Capture event detail and context before you run `confirm` or `resend`; both commands have operator-visible side effects.41- `resend` retries delivery only. It does not acknowledge or recreate the event.42- A successful `resend` does not guarantee a fresh top-level notification-history row. Delivery history is detail-based, can lag, and can be throttled by the event's minimum notification interval.43- Shared environments can surface stale events whose `event events items` call fails because the linked analysis was already deleted; try a fresher event before assuming the CLI path is wrong.44- Create alert rules from [`../idmp-workflow-alert-create/SKILL.md`](../idmp-workflow-alert-create/SKILL.md), not from this event read workflow.4546## Product behavior to preserve4748- Start with the unacknowledged-event path: count, list/search, detail, context, confirm or resend, then annotations.49- Treat confirm and batch confirm as the real acknowledgement workflow.50- Use `items` to inspect event context before retrying notifications.51- Use `annotations` to keep operator notes with the event.52- Create alert rules from alert workflows, not from the event read workflow.5354## Key commands5556```bash57idmp-cli schema event.count.list58idmp-cli event count list5960idmp-cli schema event.events.list61idmp-cli event events list --params '{"current":1,"size":20}'6263idmp-cli event events search --params '{"keyword":"overcurrent","current":1,"size":20}'64idmp-cli event events get --params '{"eventId":123}'65idmp-cli event events items --params '{"eventId":123}'6667idmp-cli event events confirm --ack-risk --params '{"eventId":123}'68idmp-cli event events confirm --dry-run --ack-risk --params '{"eventId":123}'69idmp-cli event confirm create --ack-risk --data '[123,456]'70idmp-cli event confirm create --dry-run --ack-risk --data '[123,456]'71idmp-cli event events resend --dry-run --ack-risk --params '{"eventId":123}'72idmp-cli event annotations list --params '{"eventId":123}'73```7475## Exception and failure handling7677- If an event disappears from the unacknowledged view after confirm, treat that as expected acknowledgement behavior rather than data loss.78- If `resend` succeeds, expect notification delivery to retry only; it does not acknowledge or rewrite the event.79- If `resend` succeeds but no fresh history row appears, widen the notification-history reread and consider notification throttling before assuming the retry did nothing.80- If `items` or `annotations` is empty, continue with event detail and notification checks instead of repeating confirm/resend blindly.81- If confirm or resend fails, stop retrying and inspect detail, context, and notification history before the next action.82- If list results look noisy, narrow the workflow with count, search, and detail rather than acknowledging from a broad page.8384## Validation scenarios85861. Start the unacknowledged workflow with `idmp-cli schema event.count.list` and `idmp-cli event count list`.872. Read the current queue with `idmp-cli event events list --params '{"current":1,"size":20}'` and `idmp-cli event events search --params '{"keyword":"overcurrent","current":1,"size":20}'`.883. Inspect one event with `idmp-cli event events get --params '{"eventId":123}'` and `idmp-cli event events items --params '{"eventId":123}'`.894. Acknowledge a single event with `idmp-cli event events confirm --ack-risk --params '{"eventId":123}'`, then run batch acknowledgement with `idmp-cli event confirm create --ack-risk --data '[123,456]'` or preview it first with `--dry-run`.905. Preview follow-up actions with `idmp-cli event events resend --dry-run --ack-risk --params '{"eventId":123}'` and `idmp-cli event annotations list --params '{"eventId":123}'`.
taosdata