Skip to content

koinon 26.11.7

Preserve uploads through processing failures

The upload dialog confirms a successful server acknowledgement before refreshing the list. If that refresh fails, the uploaded original remains confirmed and the interface offers a refresh without asking you to upload it again. An authorization failure clears information that the current session can no longer access.

Queued document publication now keeps its authorization lock in an explicit native transaction while document services use their own datasource. This prevents a worker from waiting on its own earlier lock during publication.

Recover a failed processing attempt

A failed native attempt can be reviewed and retried when it has no extraction, its original and version are unchanged, and its failure belongs to the current job attempt. The confirmation records that exact evidence. The worker checks it again before proceeding, preserves the original job and attempt history, and does not create another uploaded copy.

An uncertain or partially published result remains ineligible for this action. Review the bulk intake guide before recovering retained work.

Investigate email delivery and recover a welcome

Administrators can inspect a communication's submission and provider observations separately. Provider acceptance does not establish that a recipient has seen the email. Opening delivery details does not resend a message or contact the provider automatically.

An explicit welcome recovery creates a new communication linked to the original. It uses the current authorized recipient, installation identity, language and sender configuration. The review explains the possibility of duplicate delivery; a stable request key prevents a lost response from creating another recovery. Earlier communications and delivery observations remain recorded.

The Python, TypeScript and Java 21 SDKs expose the same typed review, history and confirmation operations. Follow the SDK guides and communications administration documentation for authorization and retry behavior.

Diagnose chat failures safely

Worker diagnostics identify bounded exception types and stack locations without recording exception messages, source text, local variables or credentials. Knowledge responses still require authorized source evidence; diagnostic improvements do not permit answers from unverified model knowledge.

Report the configured platform accurately

Index health establishes the authorized native workspace before opening its read-only transaction. Active indexes no longer appear missing because a database snapshot began without that scope. Email readiness uses the organization's selected verified sender and language, rather than treating multiple available senders as an unconfigured channel.

These checks report index readiness and email configuration. They do not claim that a document has finished processing or that an email reached its recipient.

Update the installation

Use version 26.11.7 consistently across runtime packages, SDKs and interface assets. The runtime remains on pyfly 26.10.32. Apply native migration koinon_0041_email_recovery and the associated least-privilege provisioning updates before starting the new runtime. Preserve existing installation identifiers, uploaded originals and historical communications.

Wait until both API and worker revisions are ready before testing a retained job. Follow installation and migration checks, then verify upload processing, a source-backed chat response and communication delivery in the running installation.