Skip to content

docs(examples): webhook automation tutorials — maintenance migration and offline-aware load balancer - #952

Draft
guthrie-vast wants to merge 1 commit into
vast-ai:mainfrom
guthrie-vast:examples/webhook-downtime-tutorials
Draft

guthrie-vast wants to merge 1 commit into
vast-ai:mainfrom
guthrie-vast:examples/webhook-downtime-tutorials

Conversation

@guthrie-vast

Copy link
Copy Markdown
Collaborator

Summary

Two new client-facing examples under Examples → Notifications, plus a shared setup snippet. They show notification webhooks as an automation hook: each delivery carries a structured data object, so an event can drive an action instead of a chat message.

  • examples/notifications/maintenance-migration.mdxMigrate an Instance Before Scheduled Maintenance. On client:upcoming_downtime, look up the maintenance window, copy state off the instance, rent a replacement on a different machine, and destroy the original after instance_started.
  • examples/notifications/offline-aware-load-balancer.mdxRoute Around Offline Instances with a Simple Load Balancer. On client:instance_offline (plural instance_ids[] / machine_ids[]), drain, blacklist the failed machine, rent a replacement elsewhere, and re-admit only after the client's own readiness probe.
  • snippets/notifications/webhook-automation-setup.mdx — shared receiver (verify → dedupe → enqueue → 2xx), webhook creation, and a local event simulator so readers can test without waiting for real maintenance.
  • docs.json — both pages added to the Notifications nav group.

Notes for review

  • The upcoming_downtime payload currently carries instance_id, machine_id, maintenance_id but not the window timing. Tutorial 1 uses POST /api/v0/machines/maintenances (renter-callable, verified against the web backend) to fetch start_time / duration_hours. When the payload is extended to include those fields, the "Look Up the Maintenance Window" step becomes a fallback; the Note in that section is the spot to edit.
  • instance_resumed fires on leaving Scheduling into running, stopped, or exited; Tutorial 2 checks actual_status before re-admitting.
  • The load balancer is deliberately minimal (buffered, stdlib proxy) so the event handling is visible. It is framed as a model for the handlers, not a production proxy.
  • All Python blocks parse; the handlers have not yet been run end to end against live instances. Draft until that is done.

Preview checklist

  • Snippet import renders on both pages (<WebhookAutomationSetup />)
  • Cross-links between the two pages and to the Slack example resolve
  • Run both handlers against a real instance with the simulator

🤖 Generated with Claude Code

Two new examples under Notifications showing webhooks as an automation
hook rather than a chat feed:

- Migrate an Instance Before Scheduled Maintenance: react to
  client:upcoming_downtime, look up the maintenance window, copy state
  off the instance, rent a replacement on a different machine, destroy
  the original after instance_started.
- Route Around Offline Instances with a Simple Load Balancer: react to
  client:instance_offline (plural payload), drain, blacklist the failed
  machine, rent a replacement elsewhere, re-admit only after the
  client's own readiness probe.

Shared setup (receiver, webhook creation, local event simulator) lives
in snippets/notifications/webhook-automation-setup.mdx and is imported
by both pages.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant