Report crashes and unhandled errors from every layer to one Sentry project via a
single build-time SENTRY_DSN (empty => disabled, so local and fork builds do not
report):
- JS/WebView + Rust panics via tauri-plugin-sentry (rustls transport; minidump
handler desktop-only).
- Android native (JVM/NDK/ANR) via sentry-android 8.47.0 with manifest auto-init
(excludes the discontinued lifecycle-common-java8 transitive).
- iOS native via sentry-cocoa started from a tracked SentrySupport/+load bootstrap
that reads the DSN from a Rust readest_sentry_dsn() FFI (no generated-file edits).
- SENTRY_DSN resolved at build time from the environment, then .env.local, then
.env (build.rs bakes it via cargo:rustc-env; build.gradle.kts for Android). CI
passes the SENTRY_DSN secret through the existing .env.local step.
Crashes + errors only: traces sample rate 0, no session replay, no PII.
Symbolication (source maps / ProGuard / dSYM upload) is a follow-up.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Since 2026-06-29 the nightly Linux legs hang forever while bundling the
AppImage and hit the job-level timeout, which reports the legs as
'cancelled'. The assemble-manifest guard treats 'cancelled' as run
cancellation and skips promoting nightly/latest.json, so nightly update
detection has been broken for ALL platforms since then (#4906).
Root cause: the truly-portable AppImage bundler in the tauri fork
downloads quick-sharun.sh from the unpinned main branch of
pkgforge-dev/Anylinux-AppImages. Upstream strace-mode changes on
2026-06-29 (acb1d719, 867c0b15) made the script execute the staged app
launcher scripts and WebKitGTK binaries under Xvfb to trace dlopened
libraries; the spawned WebKit processes survive the process-group kill
and quick-sharun waits forever.
Fixes:
- Pre-seed the tauri tools cache with quick-sharun.sh pinned to the
last known-good revision (b3a9e985, used by the green 06-27/06-28
nightlies) in both nightly.yml and release.yml. The bundler only
downloads the moving main-branch script when the file is absent.
- Add step-level timeout-minutes to the nightly build steps and raise
the job timeout to a 75-minute backstop, so a future hang fails only
that leg ('failure') instead of tripping the job timeout
('cancelled'), and assemble-manifest still promotes the manifest
fragments from the healthy legs.
Closes#4906
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Add actions/attest-build-provenance to both build workflows so every
binary is attested in the same job that builds it, the only point
where provenance meaningfully proves an artifact was built from source
rather than uploaded by hand.
release.yml (build-tauri): grant id-token and attestations write
permissions, then attest the desktop bundles via the tauri-action
artifactPaths output, the Android apks, and the Windows portable exe.
nightly.yml (build): same permissions plus one step attesting the
staged nightly-out binaries. Nightlies ship via download.readest.com,
but gh attestation verify is digest based so it verifies them too.
Verify a download with:
gh attestation verify <file> --repo readest/readest
Closes#4848
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Cherry-picked and re-verified the applicable subset of
julianshen/readest@fa1b74a0 (its "address PR #15 bot reviews" commit). The
fork-only AI-annotation-tool change was dropped — readest has no 'ai' toolbar
tool. Each logic fix is covered by a failing-first test.
- TTS position sequence is now an app-wide monotonic counter, so a fresh
TTSController (constructed per `tts-speak`) isn't dropped by consumers holding
`lastSequenceSeen` from a prior session.
- share.ts only swallows AbortError (user cancel); other failures — e.g.
NotAllowedError when a quick action fires without a user gesture — fall back to
the clipboard so the text still reaches the user.
- document.isTxt tolerates MIME params (text/plain;charset=utf-8), uppercase
extensions (BOOK.TXT), and a nameless Blob, so a TXT can't slip onto the
non-text path and yield a null book.
- updater getNightlyPlatformKey matches x86_64/aarch64 explicitly; a 32-bit or
otherwise unknown arch yields no nightly instead of mis-routing to aarch64.
- UpdaterWindow downloadWithProgress resolves on tauriDownload completion even
when Content-Length is absent (no more hang on portable/AppImage/Android).
- nightly_update.rs uses async tokio::fs::read in the async command.
- nightly.yml: serialize runs via a concurrency group (no cancel) and
persist-credentials:false on checkouts.
- edge TTS route only emits the word-boundary header when it fits under ~8KB;
oversized values get dropped by proxies, and the client falls back to [].
- RSVPOverlay drops the contradictory aria-disabled on the functional rate
button (it opens the pace picker).
- nightly verify harness handles artifact stream errors instead of crashing.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The assemble-manifest job promoted the manifest with single-file
`rclone copyto` + `moveto`. Before a single-file upload rclone issues a
CreateBucket probe (PUT /<bucket>), which the object-scoped RELEASE_R2_*
token can't satisfy -> 403 AccessDenied, so nightly/latest.json was
never published (the build legs and the stable release flow were fine
because they use a directory `rclone copy`, which PUTs the object
directly without that probe).
Mirror the release flow (upload-to-r2.yml): copy a one-file directory
into nightly/. R2 PutObject is atomic, so the .tmp + server-side move
added nothing. Verified against the live bucket with the current token:
directory copy -> 200 OK; single-file copyto -> CreateBucket 403.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The nightly Linux legs build with `cargo tauri build` WITHOUT `--target`
(no matrix `args`), so cargo emits bundles under `target/release/bundle/`
(host-target default) rather than `target/<triple>/release/bundle/`. The
macOS/Windows legs DO pass `--target`, so they legitimately get the triple
subdir — but the "collect artifacts" step reused `${rust_target}` for the
Linux AppImage path too, looking under
`target/x86_64-unknown-linux-gnu/release/bundle/appimage/` where nothing
exists. The build succeeded; only the collect step failed with
"missing artifact or signature for linux-x86_64-appimage".
Drop the `${rust_target}` subdir from the Linux AppImage path so it points
at the host-target default location where the bundle actually lands.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Huang Xin