Debug an Asset Compute worker

Asset Compute workers can be debugged in several ways, from simple debug log statements, to attached VS Code as a remote debugger, to pulling logs for activations in Adobe I/O Runtime initiated from AEM as a Cloud Service.

Logging

The most basic form of debugging Asset Compute workers uses traditional console.log(..) statements in the worker code. The console JavaScript object is an implicit, global object so there is no need to import or require it, as it is always present in all contexts.

These log statements are available for review differently based on how the Asset Compute worker is executed:

  • From aio app run, logs print to standard out and the Development Tool’s Activation Logs
    aio app run console.log(...)
  • From aio app test, logs print to /build/test-results/test-worker/test.log
    aio app test console.log(...)
  • Using wskdebug, logs statements print to the VS Code Debug Console (View > Debug Console), standard out
    wskdebug console.log(...)
  • Using aio app logs, log statements print to the activation log output

Remote debugging via attached debugger

WARNING

Use Microsoft Visual Studio Code 1.48.0 or greater for compatibility with wskdebug

The wskdebug npm module, supports attaching a debugger to Asset Compute workers, including the ability to set breakpoints in VS Code and step through the code.

Click-through of debugging an Asset Compute worker using wskdebug (No audio)

  1. Ensure wskdebug and ngrok npm modules are installed

  2. Ensure Docker Desktop and the supporting Docker images are installed and running

  3. Close any active running instances of Development Tool.

  4. Deploy the latest code using aio app deploy and record the deployed action name (name between the [...]). This will be used to update the launch.json in step 8.

    ℹ Info: Deploying package [wkndAemAssetCompute-0.0.1]...
    
  5. Start a new instance of Asset Compute Development Tool using the command npx adobe-asset-compute devtool

  6. In VS Code, tap the Debug icon in the left navigation

    • If prompted, tap create a launch.json file > Node.js to create a new launch.json file.
    • Else, tap the Gear icon to the right of the Launch Program dropdown to open the existing launch.json in the editor.
  7. Add the following JSON object configuration to the configurations array:

    {
        "type": "pwa-node",
        "request": "launch",
        "name": "wskdebug",
        "attachSimplePort": 0,
        "runtimeExecutable": "wskdebug",
        "args": [
            "wkndAemAssetCompute-0.0.1/__secured_worker",  // Version must match your Asset Compute worker's version
            "${workspaceFolder}/actions/worker/index.js",  // Points to your worker
            "-l",
            "--ngrok"
        ],
        "localRoot": "${workspaceFolder}",
        "remoteRoot": "/code",
        "outputCapture": "std",
        "timeout": 30000
    }
    
  8. Select the new wskdebug from the dropdown

  9. Tap the green Run button to the left of wskdebug dropdown

  10. Open /actions/worker/index.js and tap to the left of the line numbers to add break points 1. Navigate to the Asset Compute Development Tool Web browser window opened in step 6

  11. Tap the Run button to execute the worker

  12. Navigate back to VS Code, to /actions/worker/index.js and step through the code

  13. To exit the debug-able Development Tool, tap Ctrl-C in the terminal that ran npx adobe-asset-compute devtool command in step 6

Accessing logs from Adobe I/O Runtime

AEM as a Cloud Service leverages Asset Compute workers via Processing Profiles by directly invoking them in Adobe I/O Runtime. Because these invocations do not involve local development, their executions cannot be debugged using local tooling such as Asset Compute Development Tool or wskdebug. Instead, the Adobe I/O CLI can be be used to fetch logs from the worker executed in a particular workspace in Adobe I/O Runtime.

  1. Ensure the workspace-specific environment variables are set via AIO_runtime_namespace and AIO_runtime_auth, based on the workspace requiring debugging.

  2. From the command line, execute aio app logs

    • If the workspace is incurring heavy traffic, expand the number of activation logs via the --limit flag:
      $ aio app logs --limit=25
  3. The most recent (up to the provided --limit) activations logs will be returned as the output of the command for review.

    aio app logs

Troubleshooting

Debugger does not attach

Breakpoints not pausing

  • Error: When running the Asset Compute worker from the debug-able Development Tool, VS Code does not pause at breakpoints.

VS Code debugger is not attached

  • Cause: The VS Code debugger was stopped/disconnected.
  • Resolution: Restart the VS Code debugger, and verify it attaches by watching the VS Code Debug Output console (View > Debug Console)

VS Code debugger attached after worker execution began

  • Cause: The VS Code debugger did not attach prior to tapping Run in Development Tool.
  • Resolution: Ensure the debugger has attached by reviewing VS Code’s Debug Console (View > Debug Console), and then re-run the Asset Compute worker from Development Tool.

Worker times out while debugging

  • Error: Debug Console reports “Action will timeout in -XXX milliseconds” or Asset Compute Development Tool’s rendition preview spins indefinitely or
  • Cause: The worker timeout as defined in the manifest.yml is exceeded during debugging.
  • Resolution: Temporarily increase the worker’s timeout in the manifest.yml or accelerate debugging activities.

Cannot terminate debugger process

  • Error: Ctrl-C on the command line does not terminate the debugger process (npx adobe-asset-compute devtool).

  • Cause: A bug in @adobe/aio-cli-plugin-asset-compute 1.3.x, results in Ctrl-C not being recognized as a terminating command.

  • Resolution: Update @adobe/aio-cli-plugin-asset-compute to version 1.4.1+

    $ aio update
    

    Troubleshooting - aio update

On this page