r34 private-workflow reliability corrections — 2026-10-15

This is the retained 15 October workflow-maintenance record. Its baseline hash, validation and verifier identify that revision. The current r34 archive also includes assistant consolidation; use the current package verification command for the latest archive.

Baseline full release SHA-256: bf82ebb61c97917a7bd2baed8b75a359b7d46b476af6923f398ff5de2bd328d8.

Scope and symptoms

These corrections address My workflows refreshes, private-workflow authoring loading and failure handling, repeated storage-state reads, and native HF private-workflow execution paths. They retain the previous Astropy per-attempt reference-cache correction and all earlier release members.

The reported message Database capacity is busy; retry shortly previously covered both connection-pool acquisition timeouts and database operational errors. The supplied deployment logs did not identify the underlying database exception. This maintenance release corrects reproducible request amplification and error handling and adds sanitized diagnostics; it does not claim that the live incident's database cause has been proven.

Corrections

• Coalesce overlapping workflow refreshes and give the Refresh control a visible loading state. Returning to the page while its current read is pending does not create another identical batch of database requests. Read-only requests have a 20-second UI deadline with cancellation signaling so a stalled read does not leave Refresh disabled indefinitely; mutations and scientific execution do not inherit this deadline.
• Release private-authoring loading controls when opening fails. Display the original error without first waiting for an unrelated storage-status request. Bound supplementary reads and keep personal AI settings available independently of unrelated authoring or evidence loading.
• Reuse storage state only within the current workflow-list request instead of loading the same owner state for each listed workflow. Authorization and owner isolation remain enforced; no cross-request authorization or result cache is introduced.
• Record sanitized database failure categories, allowing a pool timeout to be distinguished from an operational error without exposing SQL, connection strings, credentials, or user payloads in the diagnostic record.
• Translate private-workflow execution paths from controller-local directories into the native HF staged execution layout. Preserve the primary failure when a rejected execution has not produced an execution.log, so missing-log cleanup no longer hides the original error.

Standalone and SaaS consistency

Shared workflow and authoring UI/service changes apply wherever those shared components are used. The execution path correction belongs to the native HF adapter and preserves the local and Docker execution paths. This maintenance does not change the scientific equations, simulation configuration meaning, AI-provider permissions, BYOK/BYOS policy, filesystem confinement, or the requirement to execute each requested simulation afresh.

The corrected private-workflow runtime descriptor advances the workflow executor identity to version 2 and records its path mode and the actual native HF network policy. Existing private-workflow validations bind to that identity. Previously validated versions may therefore require validation again before activation or execution under the corrected runtime. Their stored source, results and history are retained; the fix does not weaken those validation bindings.

A request-local storage snapshot is not a simulation-result cache. It exists only for the current read response and is discarded afterward. No previous simulation outputs are reused to satisfy a new run.

For database failures, the public response retains HTTP 503 and Retry-After: 2. Pool acquisition timeouts retain the capacity message; operational errors receive a general database-unavailability message. PF_DATABASE_UNAVAILABLE diagnostics record the error category, validated SQLSTATE when available, route template and bounded numeric pool snapshots. A pool snapshot does not identify which pool failed; the diagnostic explicitly records that as unknown.

Targeted validation and hash records

Only the targeted checks listed in release_tools/workflow_reliability_checks.json are run for this correction. Their exact command lines, source freeze, logs, JUnit counts and skips are bound in validation_r34_workflow_reliability/test_execution.json. That receipt and the release group ledger distinguish new test executions from historical results. No historical benchmark, scientific validation, or regression count is relabeled as a new execution.

The current registries use schema 32.0.0 and retain the Astropy maintenance registries as their immediate historical predecessor. The packaging tool preserves every baseline member and the original bytes of changed files under validation_r34_workflow_reliability/original_files/. It refreshes the current manifest, complete package checksums and archive hash sidecar after successful targeted checks.

Verify the complete extracted release:

python release_tools/package_r34_workflow_reliability.py verify --package

These local checks do not certify production capacity, a full scientific regression, live HF execution, native Windows execution, external AI/BYOS providers, or external scientific replication. Live deployment and a short post-upgrade workflow/authoring smoke check remain separate steps.

HF deployment

Use the full native-release upgrade procedure in docs/R34_NATIVE_HF_RELEASE_UPGRADE.md. The controller and the pinned private code archive must come from the same new bundle. Uploading only browser assets would omit the service and execution corrections. Generate the bundle with the included deploy/saas/huggingface_native/build_space.py; its deployment evidence binds only the files actually deployed and does not promote historical scientific records to live qualification.

Preserve the current private state backup and configuration, including the state Bucket, privacy, registration policy, credentials, and capacity limits. The release itself performs no live HF changes, rollback, schema reset, credential changes or data deletion. Retain the established prepare/apply/status checks and resolve any uncertain commit response before another write.