From a wiki read to a Phoenix trace: check the same workflow run

A workflow pilot is easier to review when its run record, response and trace refer to the same execution. Opening a designer or a tracing dashboard proves that an interface is reachable. It does not establish that the intended task completed.

This exercise reads one public wiki page. It does not require a paid model call, customer data or a vendor account beyond the operator's own workflow environment. Keep the existing flows intact and use a named isolated pilot.

Define the narrow flow

Use one authorized manual or webhook event followed by one HTTP GET to a public article. Disable automatic retries for the initial check so a single request remains distinguishable. Record the flow version, target URL and observation time. Do not add message sending, account updates or private data exports.

Use the installed Activepieces version's documentation and actual API schema. A public recipe for a different version may use a different endpoint or request body. A configuration accepted by the API still needs an execution record.

Collect the execution evidence

The Activepieces Flow Runs reference describes the run listing and its statuses. After triggering the isolated flow, locate its run by both flow ID and run ID. Inspect its terminal status and the HTTP step's actual result.

A 200 response containing a login page is not the desired article. Check the page identity or expected content as well as its HTTP status. A queued run is not a completed run. Preserve a failed or timed-out run instead of replacing its evidence with a screenshot of a later success.

Link the observations to Phoenix

Phoenix receives instrumented spans over OTLP, as described in How Tracing Works. Use one trace ID for the observed operation, and record the actual workflow run ID as an attribute. Record only timestamps that were observed; do not invent child steps or model calls to make the trace look complete.

An observer that submits the webhook, reads the run and exports spans is manual instrumentation around those operations. It is not proof that every internal Activepieces worker or the remote wiki server automatically emitted spans. A propagated traceparent header also does not make an uninstrumented server produce a span.

The operator's Phoenix workspace is protected. Use the existing authorized login. Do not place its password, API keys, authorization headers or private response bodies in a public article, trace attribute or screenshot.

Read back what was stored

Confirm that the trace is readable in Phoenix and its run ID matches the recorded workflow execution. Compare the reported outcome with the workflow's own result. A successful OTLP request alone does not establish that the intended spans can be found.

For repeated runs, keep a small checkpoint keyed by run ID and flow version. This avoids sending the same observation repeatedly. If an export result is uncertain, preserve that uncertainty and inspect the collector before replaying it.

Accept only the demonstrated scope

The exercise passes when the named run reaches the expected terminal state, the intended public article is present in its result, the trace can be read back and the IDs match. Record failures separately. This establishes one read-only workflow path; it does not certify all connectors, every user account or a production observability service.

Wiki Connections

• ai pilot evidence and human review
• source linked answers practice
• mcp permissions first practice