feat(incidentio): add on-call, alert, catalog, and team tools - #6529
Conversation
Adds 19 tools to the incident.io block, taking it from 46 to 65 operations. Every endpoint, param, and response field is taken from the official OpenAPI spec at api.incident.io/v1/openapiV3.json. Who is on call had no reachable answer before: the data lives in ScheduleV2.current_shifts, and both schedules_list and schedules_show returned it but never declared it. The new incidentio_on_call_now tool flattens current and upcoming shifts to one row per person, and the two existing schedule tools now declare the fields they were already returning. Also fixes two pre-existing wiring bugs: the block declared an output named schedule_override while the tool emits override, and the on-call handoff skill described a lookup the integration could not perform.
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
PR SummaryMedium Risk Overview On-call: Adds Alerts & escalations: New list/show/resolve, HTTP alert event firing (separate Catalog, teams, incident work: Catalog types/entries, team list/show, follow-up and action create/update, incident participants, and private-incident membership grant/revoke. Fixes: Block output Reviewed by Cursor Bugbot for commit 6c89d4f. Configure here. |
Greptile SummaryThe PR expands the incident.io integration with on-call, alert, catalog, team, follow-up, action, escalation, and incident-membership operations, while correcting schedule output declarations.
Confidence Score: 5/5The PR appears safe to merge because no blocking failure remains within the eligible follow-up-review scope. No blocking failure remains.
|
| Filename | Overview |
|---|---|
| apps/sim/blocks/blocks/incidentio.ts | Adds operation choices, conditional inputs, parameter transformations, and output declarations for the expanded Incident.io toolset. |
| apps/sim/tools/incidentio/index.ts | Exports the newly added Incident.io tools for registry consumption. |
| apps/sim/tools/registry.ts | Registers the new Incident.io operations with the shared tool runtime. |
| apps/sim/tools/incidentio/on_call_now.ts | Adds an operation that retrieves schedules and flattens current and upcoming shifts into on-call rows. |
| apps/sim/tools/incidentio/alerts_list.ts | Adds alert listing with pagination and bracket-operator filters, including tri-state boolean handling. |
| apps/sim/tools/incidentio/alert_events_create.ts | Adds HTTP alert-event creation using a separately supplied alert-source credential. |
| apps/sim/tools/incidentio/types.ts | Extends Incident.io parameter, response, and output types for the new operations. |
| apps/docs/content/docs/en/integrations/incidentio.mdx | Documents the expanded operation set, parameters, and workflow outputs. |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart LR
User[Workflow block inputs] --> Block[Incident.io block config]
Block --> Transform[Parameter transforms]
Transform --> Registry[Tool registry]
Registry --> Tool[Selected Incident.io tool]
Tool --> API[incident.io API]
API --> Response[Response transform]
Response --> Outputs[Declared workflow outputs]
Reviews (2): Last reviewed commit: "fix(incidentio): stop the alert filter s..." | Re-trigger Greptile
The has_notes and include_maintenance_window dropdowns default to the
string "any", meaning "do not filter". The params transform skipped the
key in that case, but the executor merges its output over the raw inputs
(`{ ...inputs, ...transformedParams }`), so the sentinel survived and the
tool sent has_notes[is]=any, which incident.io rejects.
The transform now always assigns the key, mapping "any" to undefined so
it overwrites the sentinel instead of leaving it in place. The tool also
only serializes these filters when it actually has a boolean.
Adds tests covering the sentinel, both real boolean values, and the
documented bracket-operator filter syntax.
|
@cursor review |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 6c89d4f. Configure here.
Summary
ScheduleV2.current_shifts, and bothschedules_listandschedules_showreturned it but never declared it. Newincidentio_on_call_nowflattens current and upcoming shifts to one row per person per schedule; the two existing schedule tools now declare the fields they were already returningschedule_overridewhile the tool emitsoverride, and the on-call handoff skill described a lookup the integration couldn't performEvery endpoint, param, and response field comes from the official OpenAPI spec at
api.incident.io/v1/openapiV3.json— nothing inferred. Things that would have been wrong if guessed:page_sizeis required on/v2/alerts,/v2/incident_alerts, and/v3/catalog_entriesstatus[one_of]=firing); the source filter param isalert_source, notalert_source_idalert_events_createauthenticates with the alert-source token, not the org API key, so it has its own credential fieldcreatoris an actor envelope ({user?, api_key?, workflow?, alert?}), not a userType of Change
Testing
Typecheck, lint,
check:api-validation,tool-metadata:check, andintegration-catalog:checkall pass. Wrote a throwaway script asserting every dropdown operation has a registry entry, a selector case, reachable required params, and declared block outputs — 65/65 clean.Not exercised against a live incident.io account (no credentials).
Known gap left alone
actions_showandfollow_ups_showreadcreator.id/name/email, which don't exist on the actor envelope — those fields return undefined today. Fixing it changes existing tool outputs, so I left it out of this PR.Checklist