Processing Failures Have a Recovery Path
Arivu administrators can now inspect durable job and summary failures, retry eligible work safely, and keep the original history for diagnosis.
A background failure should not leave a self-hoster choosing between guessing, editing the database, and pretending the work never happened.
Arivu Administration now makes processing failures visible and recoverable. The API Usage view lists durable failed jobs and failed summaries with the context needed to decide what to do next: the owner, affected bookmark, attempts, timestamps, provider and model context where relevant, safe error information, and recorded failure details.
Failures Stay Attached to the Work
Failed jobs and failed summaries are shown separately because they answer different operational questions. A background job may have exhausted all of its attempts. A summary may have failed evidence or validation checks without exhausting the surrounding job.
Bookmark links take an administrator back to the affected item. The bookmark and its last good evidence remain available, so investigating a failed refresh does not require sacrificing the readable copy a user already had.
What this means for you: processing problems are visible as durable records rather than unexplained missing output.
Retry Without Erasing History
An administrator can retry one eligible failed bookmark-processing job, select several failures, or retry the most recent failed processing attempt per bookmark for a specific user. Broad recovery can therefore follow a small verified retry instead of starting with every failure at once.
A retry creates a new queued job. It does not mutate or delete the original failure. Arivu rejects unsupported job types and duplicate active retries, and bulk results show how many jobs were queued or skipped.
Administrative retries are also audited. If a provider, capture runtime, storage issue, or network problem returns, the original failure and the recovery action remain available for diagnosis.
Recovery Is Deliberate
The retry controls are not an automatic loop that keeps spending resources against an unresolved problem. Check the recorded reason, inspect the bookmark, resolve the underlying condition, and retry a small selection first. Use the per-user action after the first recovery is healthy.
Existing user management, runtime settings, system status, audit history, and provider-optional bookmark processing remain intact. The change is operational clarity: administrators can see what failed, choose what is safe to repeat, and retain the evidence of both events.
Read Administration and Recovery for the current workflow and Preservation and Sharing for capture fallback and last-good evidence behavior.