mirror of
https://github.com/phantomptr/ps5upload.git
synced 2026-10-22 03:42:55 -05:00
77040f75bb
* Implement PS5UPLOAD_BASE_URL environment variable * Format engine Rust sources * Check and remove trailing slash on VITE_BASE_URL * Add base path to logo-square.png * Fix Base URL 404 error * Update Docs * Comment Backend code * fix(engine): clear two latent toolchain-gate failures on current stable Both reproduce on a clean checkout with the engine CI's own commands on current stable Rust; CI only passes today because its cargo cache carries forward lint/compile results from an earlier toolchain, so any cache miss or contributor build fails. - ps5upload-fpkg `free_bytes`: `st.f_bavail as u64 * st.f_frsize as u64` trips clippy `unnecessary_cast` (`-D warnings`) because the statvfs fields are already u64 on Linux. The cast is still needed on macOS, where they are u32, so keep it, silence the lint on the targets where it is a no-op, and use `saturating_mul` so the 32-bit path cannot overflow (the bare `*` would panic in debug). - ps5upload-core fs_ops test: `AtomicU8::try_update` is an unstable library feature (E0658) on current stable, so `cargo test -p ps5upload-core` fails to compile. Switch to the stable `fetch_update`; the call only inspects `.is_ok()`, which is true for both exactly when the closure returns `Some`, so behaviour is unchanged. Verified: `cargo clippy --workspace -- -D warnings` and `cargo test -p ps5upload-core` both pass. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DtgLppKgEWNbr47WHg1tsu * test(ava1): lane-scaling measurement is checked locally, not on CI `lanes_grow_on_a_link_that_scales_with_them` asserts the governor opens a fourth lane when extra lanes raise throughput through a per-lane cap. That only holds at native speed: a shared CI runner cannot always give the fourth lane the headroom to pay off (3 lanes seen on main, 4+ on the same commit in its PR), and under coverage the instrumented sender stalls the capped 160 MiB transfer outright. Skip the coverage run entirely and the lane-count assertion on CI; the transfer-succeeds assertion still runs everywhere. This is the same fix as PR #389 (identical diff), ported here so this PR's `rust (engine workspace)` job goes green on its own; it no-ops once the base carries either copy. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DtgLppKgEWNbr47WHg1tsu * fix(ava1): a stalled upload cancels its job so the destination frees for a resume When an upload stalls fatally (no frame fits the receiver's window and nothing is sent, received or credited for the stall limit), the sender broke with a Protocol error but, unlike every other fatal exit (ERR_IO, ERR_VERIFY, ERR_CANCELLED), sent the console no JobCancel. The console was never told the job died, so it kept the job alive holding the destination. The next attempt's JobOpen was then refused BUSY ("another transfer is writing to this destination") until its retries ran out — the two failures a user sees back to back: a 600 s credit stall on one attempt, then "stayed busy for 12 retries" on the next. Send a JobCancel (reason ERR_STALLED) before giving up, matching the other fatal paths. The journal and the .ava-part stay, so this frees the destination for a clean resume rather than a conflict. Extends the existing `a_grant_smaller_than_one_group_fails_loudly_instead_of_hanging` test to assert the receiver sees the cancel. This does not change why a console grants a sub-group window and stops returning credit (the stall's root cause is in the console-side AVA1 receiver); it makes the stall tear down cleanly so a retry can recover. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DtgLppKgEWNbr47WHg1tsu * test(ava1): de-flake two C-interop tests that failed CI on timing, not on bugs The gating `rust (engine workspace)` ctest step flaked on a rotating set of timing-sensitive tests under CI load (all pre-existing on main, none caused by this PR). Two of them are now robust: - `a_rate_capped_link_is_reported_as_the_network` (governor.rs): a bottleneck *classification* assertion, meaningful only at native speed. On a shared CI runner the debug sender is slower than the 8 MiB/s cap, so the link is not the sole bottleneck and the label describes the runner, not the code. Add the `CI` arm to the skip guard that already covers the sanitizers and coverage — the same guard its sibling `a_slow_disk_is_reported_as_the_bottleneck` already carries. The transfer-succeeds assertion still runs everywhere. - `lane_killed_mid_chunk_requeues_and_completes` (upload.rs): asserts a data-lane kill never costs the session (`sessions == 1`). It killed "the newest connection" via ChaosProxy, which races onto the control connection right after a reconnect or before the first lane opens — dropping the session and failing the assertion (reproduced on clean main, ~1 in 3 locally). Add `ChaosProxy::kill_newest_lane`, which never targets the control connection (the oldest live one), and use it here. The session now survives the kill by construction; the assertion is unchanged and passed 8/8 locally after the fix. Not a weakening of either test: the first keeps its transfer check and only drops an environment-dependent label on CI (matching the existing sibling); the second still proves a lane kill is absorbed, now without the control-connection race. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DtgLppKgEWNbr47WHg1tsu --------- Co-authored-by: GosDev <39804434+GospelBG@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>