Testing & Error Handling

How to test your plugins, debug failures, and handle errors in production.
View as Markdown

Building a plugin is only half the work. Before you publish, you need to verify it works — and plan for what happens when it doesn’t.

Testing Your Plugins

How you test depends on what you built.

Testing Compound Actions

Compound actions have a Test button in the Agent Studio editor. Click it to:

  1. Enter sample input arguments
  2. Execute the compound action
  3. View step-by-step logs showing what happened at each expression

This is the fastest way to validate your logic before wiring the compound action into a plugin.

This is also how you test scheduled trigger plugins — since you can’t manually fire a schedule, test the compound action directly using the Test button.

Testing Script Actions

Script actions also have a Test button in the editor. Enter your input variables and run the script to verify the output before using it in a compound action.

Testing Conversational Plugins

Conversational plugins must be tested through the AI assistant — not through Agent Studio. After publishing your plugin:

  1. Open a chat with your AI assistant
  2. Type one of your triggering utterances (e.g., “Check my PTO balance”)
  3. Walk through the conversation flow — fill slots, confirm actions, verify responses

Plugins take approximately 10 seconds to deploy after publishing. If your plugin doesn’t trigger immediately, wait a moment and retry.

Testing Ambient Agents (Webhook-Triggered)

For webhook-triggered plugins:

  1. First, test your compound action using the Test button (see above)
  2. Then send a test webhook to your listener URL using cURL or a tool like Postman
  3. Check the plugin logs for execution results
$curl -X POST "https://api.moveworks.ai/webhooks/v1/listeners/<LISTENER_ID>/notify" \
> -H "Content-Type: application/json" \
> -d '{"your": "test payload"}'

For details on webhook security and listener configuration, see System Triggers.

Error Handling

HTTP Action Errors

When an HTTP action returns a non-2xx status code, the action fails. Common scenarios:

Status CodeMeaningWhat to Do
400Bad RequestCheck your input mapping — a required field may be missing or malformed
401 / 403Unauthorized / ForbiddenVerify your connector credentials and permissions
404Not FoundCheck your endpoint URL and path parameters
429Rate LimitedReduce request frequency or contact the API provider about rate limits
500Server ErrorThe external system failed — use try_catch to handle gracefully

HTTP actions have a 60 second timeout. If your API is consistently slow, work with the API provider to optimize response times, or consider breaking the request into smaller calls.

Error Handling in Compound Actions

Use try_catch to handle failures gracefully:

1- try_catch:
2 try:
3 steps:
4 - action:
5 action_name: update_record
6 output_key: update_result
7 input_args:
8 record_id: data.record_id
9 catch:
10 on_status_code: [404, 500]
11 steps:
12 - raise:
13 output_key: error_result
14 message: >-
15 Failed to update record {{record_id}}.
16 Please try again or contact support.

You can filter by specific status codes using on_status_code, or catch all errors by omitting it.

Use raise to explicitly throw an error and exit the compound action when a precondition isn’t met.

Conversation Timeouts

Be aware of the execution time limits:

ScopeTimeout
Single action step30 seconds (recommended target)
Determined execution plan45 seconds
Entire request lifecycle160 seconds

If an action might exceed 30 seconds, consider running it asynchronously — uncheck Wait for Completion on the action activity, or use delay_config in compound actions.

Debugging with Logs

After executing a plugin, check the Logs section in Agent Studio for detailed execution traces. Key log types:

  • Action logs: Input/output for each action step
  • Compound action logs: Step-by-step execution with status codes
  • Webhook logs: Listener trigger events and payload data

For webhook-specific debugging, see Webhook Logs Troubleshooting Guide.

Checklist Before Publishing

Before making your plugin available to users:

  • Tested the core action (HTTP or compound) with realistic input data
  • Verified error handling — what happens if the API returns 400? 500?
  • Checked response sizes — will the output trigger SDA (over 7K tokens)?
  • Confirmed slot validation catches invalid input
  • Tested with the AI assistant using natural language (for conversational plugins)
  • Verified launch configuration restricts access appropriately
  • Reviewed the Golden Rule — no two action activities back-to-back without a slot in between