Recover tasks and deliveries

Use task instances to follow long-running Golden work. Use product events to follow records waiting for or failing delivery through configured destinations.

Before you begin

Task administration requires ADMIN. Administrators and stewards can read product events and event statistics; revalidating or deleting events requires ADMIN. You need the entity, task, or destination identifier associated with the operation you are diagnosing.

Follow a task

1. Open Tasks and select the Executions view.
2. Locate the task created by the operation, using its identifier and start time rather than its name alone.
3. Follow it until it reaches a terminal state.
4. Read the task’s progress and messages before deciding on recovery.

Use the canonical task status reference to distinguish active and terminal states. Do not start another copy while work is active; duplicate runs can repeat data-changing operations.

Review schedules

1. Open the Schedulings view.
2. Confirm that the intended scheduling is enabled.
3. Review its schedule before changing it or choosing Run now.
4. After a scheduled start, locate the new task instance and follow its result.

Changing a schedule affects future runs. Running it immediately creates a separate execution and does not replace the schedule.

Review destination events

Event inspection and recovery require ADMIN.

1. Open Events.
2. Select the destination whose delivery outcome you need to inspect.
3. Filter the view to pending or invalid events as appropriate.
4. Open an event and review its customer-visible message and record context.
5. Resolve the destination or data issue.
6. Ask an administrator to revalidate the event before delivery is retried.

Deleting or clearing events can remove pending delivery work. Use those actions only under an approved recovery procedure.

Inspect events through the API

List one destination’s events:

curl --fail-with-body --silent --show-error \
  --header "Authorization: Bearer ${GOLDEN_ADMIN_TOKEN}" \
  "${GOLDEN_URL}/api/events/sink/${SINK_ID}?filter=INVALID&pageNumber=0&pageSize=10"

filter accepts ALL, VALID, or INVALID. An event reports id, sink, payload, created, modified, error, and valid. Treat payload as customer data and exclude it from ordinary support requests.

Use GET /api/events/id/{id} for one event. Administrators can retry an invalid event with PUT /api/events/valid/{id}, delete one with DELETE /api/events/id/{id}, or clear one destination’s events with DELETE /api/events/sink/{id}.

Read destination statistics

GET /api/events/stats reports, per destination:

• stalled, whether delivery is currently waiting;
• nextCheck, the next reported retry time when stalled; and
• eventsCount, the number of events pending delivery.

Use these fields to distinguish an empty queue from a destination that is waiting to retry. Do not infer infrastructure health from them.

Verify the result

• The task reaches SUCCEEDED, or the event no longer appears as invalid.
• The affected entity returns to its expected state.
• A read or destination-side verification confirms the intended records are available.

If the problem continues

Collect the product version, time range, entity or destination identifier, task or event identifier, terminal status, X-Trace-Id, and displayed error messages. Do not include tokens, customer record contents, or internal diagnostic data in a support request unless an approved secure channel requests them.