r34 tracking preparation and controller recovery

This is the retained tracking-recovery record. Its baseline hash and successful user-supplied run identify that revision, not a new test of the latest archive. The current full release retains these fixes and adds configuration consistency Astropy reference-cache initialization, workflow reliability and Assistant consolidation. Use the current package verification command for the latest archive.

This full r34 maintenance release merges the two deployed HF patches into the base archive with SHA-256 da93bac5d033dc6dc2ac6655b4e72078865c358346c3d9a3e857f64809186f7b. It retains the standalone, SaaS, private-workflow, BYOK/BYOS and earlier execution recovery contents. No new third-party dependency or database migration is added by these tracking changes. The release version remains r34.

Merged application changes

The controller follow-up versions of worker.py and tracking_inputs.py supersede their earlier preparation-patch versions. All six final application files are byte-identical to the patches composed in that order. Separate qualification routing and HF context-builder changes make the new release's validation records discoverable and include them in generated deployments.

Cache, progress and failure behavior

The public tracking cache is in process memory, bounded to 32 MiB and 128 entries. GP data can be reused for up to two hours and timing inputs for up to 24 hours; original acquisition timestamps and content hashes are retained. Per-run freshness, time coverage, leap expiry, catalog identity and scientific validity checks still apply. A cache hit is not permission to use stale or invalid inputs. Restarting the controller clears this cache.

Concurrent requests can share a valid public download. Source serialization and transport cooldowns limit repeated acquisition attempts. Non-200 provider responses stop further provider requests for operator review; an invalid catalog response is scoped to its URL. The worker prepares and freezes the validated inputs before dispatching isolated scientific execution.

Tracking log callbacks use a bounded per-attempt buffer and no longer wait on the lock held by remote checkpoint publication. Checkpoint and final artifact publication drain that buffer under their existing synchronization. Final publication can still take time and waits for the checkpoint writer to finish; this change does not eliminate all storage or run latency.

After a CelesTrak TCP TimeoutError, the controller can run a bounded connectivity check once per process for already-allowed tracking hosts. It sends no HTTP requests, uses verified TLS and retains the original failure. The network-wait budget is 20 seconds with up to three seconds per operation; cancellation/lease checks and final publication can add time. If triggered, the run retains controller-connectivity.json and operator logs contain PF_CONTROLLER_CONNECTIVITY. Successful preparation need not produce this failure diagnostic. Do not restart repeatedly merely to rearm it.

The earlier standalone HF Job connectivity diagnostic is a troubleshooting utility and contains no product fix. Its script, patch rollback helpers, instance-specific controller manifests and deployment receipts are not installed as application code by this merge.

Validation and evidence

Only targeted checks are run for this maintenance release: cache and acquisition behavior, deadlines and transport diagnostics, worker log/request retention and publication, preparation UI labels, and release/context integrity. The exact commands, results and source hashes are recorded in validation_r34_tracking_recovery/test_execution.json and its immutable run receipt. Full regression and production capacity tests are not rerun.

Separately, user-supplied HF evidence shows a completed ten-session comparison, visible logs and populated Orbit comparison plots. All 464 native artifact hash/size records, six tracking inputs and 260 session-manifest references match the supplied run archive. Its source provenance matches the merged application files. The 20 passing runtime validation reports in that run are existing live evidence, not newly executed release tests. A privacy-safe summary is retained in validation_r34_tracking_recovery/user_supplied_live_run_summary.json.

That successful run does not identify the external cause of the earlier TCP timeout, qualify all study purposes or establish concurrency, provider availability, empirical tracking accuracy or a measured PF advantage. Historical validation directories and their totals are preserved unchanged.

Verify and deploy

Compare the delivered archive with its .sha256 companion, extract into a new folder and run from the privileged-frame-simulation root:

python release_tools/package_r34_tracking_recovery.py verify --package

Build new HF contexts from this full source using the existing native deployment guide. Generated code archives receive new SHA-256 values and commit pins; never reuse a previous release's code hash as the identity of a new build. The runtime-image source is unchanged by this merge. Follow the normal runtime source verification and code qualification steps instead of assuming an image or code pin from a previous deployment.

For existing installations follow the native HF upgrade procedure. Preserve private state, keys and the stopped, verified backup required by that procedure. Do not apply the earlier baseline-specific patches over this already merged full release. A running deployment that has both patches already has the six merged application changes; generating this archive does not modify that deployment.

Standalone and Linux/Docker users continue to use their existing deployment profiles. This focused maintenance validation does not replace live qualification of those environments.