ON THIS PAGE

Testing and Deploying Actions

Before an Action can be deployed, it must pass a test run. Testing executes your current code against a selected device and a sample payload that matches your trigger’s Packet Schema. The Deploy Action button will only become enabled after a successful test.

Prerequisites
  • You need at least one device in your project to run a test.
  • If your schema defines fields, either use the default randomized values, manually enter values for those fields, or ignore this if the incoming message trigger has no fields.

Run a test
  1. Open your Action. The right panel shows Action Test with the current Status (Pending, Successful, or Error).
  2. Select Device. Choose which device the incoming message should be tested against.
  3. Choose payload mode:
    • Randomize payload: toggle ON to auto‑generate valid values for every field in the schema.
    • Manual payload: toggle OFF to enter values yourself. The form shows each field name, its type (e.g., boolean, decimal, i64), and a validity indicator.
    • If your schema has no fields, you can ignore the payload section.
  4. Click Test Action. The Action status will update accordingly.

Notes:

  • Inline editor linting highlights many issues before you run the test, but runtime errors can still occur.
  • The sandbox enforces a 500 ms execution limit. Overruns are terminated. You will be able to see this in the action test failure logs below the code editor.

Reading test results

After execution, the Action Test Results panel below the editor summarizes the action run result:

  • Success
    • You’ll see “Action Executed Successfully.”
    • Console output is listed in order with labels like console.log and console.warn.
    • Each effect shows what was attempted and validated—for example, a send_mail entry with Device, Schema, and the validated Payload.
  • Failure (Error)
    • The Status shows Error/Failed.
    • The results panel lists the first error (for example, “Syntax Error: 'engine' is not defined”).
    • Editor linting markers and inline messages help you fix invalid identifiers, missing resources, or argument mistakes.
    • Invalid inputs in the payload form are marked with type hints and validity indicators; correct them and re‑run the test.

Tip: The timestamp for each step of the action test is shown in the results/logs as well.

Deploy the Action

When the latest test result is Successful, the Deploy Action button becomes enabled.

  • Click Deploy Action to make your current code live.
  • New incoming messages that match the trigger schema will run the deployed version.
  • Use Show Logs to inspect production runs after deployment.

Troubleshooting
  • Test Action is disabled
    • Select a device first.
  • No payload form appears
    • Your trigger schema has no fields; this is normal.
  • Randomize payload does nothing
    • Ensure the toggle is ON. If your schema has fields, randomized valid values are generated automatically.
  • Empty dropdowns for devices/tags/webhooks/schemas
    • Add the missing resources in your project. The editor and test UI only allow selecting existing resources.
  • Test fails with validation errors
    • Ensure payload values match the schema’s field types (e.g., boolean, decimal, i64).
  • Test times out or seems slow
    • Keep the action lightweight. The runtime kills executions exceeding 500 ms.
  • Logs differ between test and live runs
    • Tests show console.debug and console.log output; in live runs, console.warn and console.error are persisted.

What deployment changes

Deploying replaces the currently active code for this Action. Triggers after deployment use the new code, and any outbound messages your action sends are enqueued per device into their mailboxes, where each device processes messages sequentially.

For writing code and using the fostrom.* APIs, see Writing Actions. For viewing production logs with filters and details, see Action Logs.