[Due for payment 2026-07-23] [$250] [Sentry: APP-1VG] HybridApp Android PdfDocument Already closed on receipt render

[mountiny]

Sentry

https://expensify.sentry.io/issues/APP-1VG

Impact (snapshot at filing)

• Users (total since first seen): 438
• Events: 885
• Users (last 14d, 9.4.x releases): 9
• First seen: 2025-12-02
• Last seen: ongoing
• Platform: Android HybridApp
• App version(s): 9.4.5–9.4.9
• Affected route(s): TransactionReceipt view
• Mechanism: UncaughtExceptionHandler

Stack trace (top frames, first-party only)

io.legere.pdfiumandroid.PdfDocument.openPage
com.github.barteksc.pdfviewer.PdfFile.renderPageBitmap
com.github.barteksc.pdfviewer.RenderingHandler.proceed

Suspected cause

PDF document is closed while the renderer thread still tries to open a page — race in receipt PDF viewing.

Reproduction

Unknown — see Sentry events linked from the Sentry issue.

Related

• Prior GH issues: none

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022067266143231416523
• Upwork Job ID: 2067266143231416523
• Last Price Increase: 2026-06-17

Issue Owner

Current Issue Owner: @eVoloshchak

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @eVoloshchak (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022067266143231416523

[godzillaxbox19982014-lgtm]

Proposal

Please re-state the problem that we are trying to solve in this issue.

[$250] [Sentry: APP-1VG] HybridApp Android PdfDocument Already closed on receipt render

What is the root cause of that problem?

I traced this to the path that handles APP, 1VG, HybridApp:

• src/components/MoneyRequestConfirmationListFooter/ConfirmationReceiptThumbnail.tsx:137 (ConfirmationReceiptThumbnail): sentryLabel={CONST.SENTRY_LABEL.REQUEST_CONFIRMATION_LIST.PDF_RECEIPT_THUMBNAIL}
• src/components/ReportActionItem/ReceiptPDFOverlay/index.tsx:60 (index): pointerEvents="none"
• src/components/ReportActionItem/ReceiptPDFOverlay/index.native.tsx:9 (index.native): return null;
• The local evidence matches this recurring failure shape: native callback assumes current policy/report still exists. Here, src/components/MoneyRequestConfirmationListFooter/ConfirmationReceiptThumbnail.tsx:137 and src/components/ReportActionItem/ReceiptPDFOverlay/index.tsx:60 do not agree on the same APP, 1VG, HybridApp value, so the user-visible path can show a missing or stale state even though nearby data already has the needed context.

What changes do you think we should make in order to solve the problem?

• Update src/components/MoneyRequestConfirmationListFooter/ConfirmationReceiptThumbnail.tsx:137 to derive APP, 1VG, HybridApp from the matched app state path that owns this flow before the value is consumed.
• Carry the same normalized value through src/components/ReportActionItem/ReceiptPDFOverlay/index.tsx:60; that follows the safer family move to add the guard at the ownership boundary, not only at render, so the write/optimistic/read paths agree instead of only changing the visible component.
• Keep the change inside the Sentry Crash, Null/Undefined, Native Hybrid surface and avoid changing do not hide crashes with blanket catch, native platform differences.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

1. Add or update a regression in tests/unit/**/*.ts for the exact issue flow: [$250] [Sentry: APP-1VG] HybridApp Android PdfDocument Already closed on receipt render.
2. Cover the counter-case near src/components/MoneyRequestConfirmationListFooter/ConfirmationReceiptThumbnail.tsx:137 so valid existing APP, 1VG, HybridApp behavior still works.
3. Manually repeat the issue steps after the patch and confirm the visible state/action is no longer stale.

What alternative solutions did you explore? (Optional)

• I would not add a broad new condition outside these referenced paths; the safer fix is to keep APP, 1VG, HybridApp consistent at the first read/write boundary shown above.

[MelvinBot]

Proposal

Posted by MelvinBot — confidence: High on root cause, Medium on the proposed fix (needs a build test).

Please re-state the problem that we are trying to solve in this issue.

On Android HybridApp, viewing a receipt PDF crashes with an uncaught IllegalStateException("Already closed") thrown from io.legere.pdfiumandroid.PdfDocument.openPage, on the background render thread (RenderingHandler.proceed → PdfFile.renderPageBitmap → PdfDocument.openPage). 885 events / 438 users since 2025-12-02, still happening on 9.4.5–9.4.9.

What is the root cause of that problem?

The existing patch that was meant to fix this is a no-op for the crashing code path.

App already ships react-native-pdf+7.0.2+002+fix-pdf-crash-already-closed-android.patch, which sets AlreadyClosedBehavior.IGNORE in the PdfView constructor. But in io.legere:pdfiumandroid:1.0.35 (the version react-native-pdf depends on), PdfDocument.openPage is one of the few methods that does not consult that config — it uses Kotlin check(!isClosed) { "Already closed" }, which throws unconditionally. So the IGNORE setting has zero effect on openPage.

On top of that, the underlying defect is a teardown race: navigating away triggers onDetachedFromWindow → recycle() → pdfFile.dispose() (which closes the document), while the background render thread is still mid-render. quitSafely() only drains queued messages, not the one already executing — so the render thread reaches openPage after the doc is closed and crashes.

Evidence

• openPage ignores the IGNORE config (pdfiumandroid 1.0.35): PdfDocument.kt:142-158 uses check(!isClosed) { "Already closed" }. Sibling methods (openPages, deletePage) in the same file do call handleAlreadyClosed(...) — openPage was never updated. This asymmetry persists through the final v1.x release (1.0.35); it was only fixed in 2.x, which has a breaking API change (openPage returns nullable).
• The patched config call: patch 002 only adds ConfigKt.setPdfiumConfig(new Config(new DefaultLogger(), AlreadyClosedBehavior.IGNORE)) in the constructor — no try/catch, nothing on the render path.
• The race / no draining: PDFView.java recycle() calls pdfFile.dispose() (closes the doc) without joining the render thread; RenderingHandler.handleMessage only catches PageRenderingException, so the IllegalStateException escapes and crashes the process.

Why the existing proposal above doesn't apply: the other proposal points at ConfirmationReceiptThumbnail.tsx / ReceiptPDFOverlay React components and a generic "stale state" theory. This crash is entirely inside the native Android PDF libraries on a background render thread — those JS/TS components are not in the crash path.

What changes do you think we should make in order to solve the problem?

The exception-handling and thread-draining code lives inside the compiled com.github.zacharee:AndroidPdfViewer:4.0.1 AAR, which patch-package cannot edit. The only files we can patch are react-native-pdf's own PdfView.java and build.gradle. So the fix must come from the subclass layer:

Recommended: Override recycle() in PdfView.java (it extends PDFView, and recycle() is public/overridable) so it drains the render thread before the document is closed. Because renderingHandlerThread is private in PDFView, access it via reflection, then quitSafely() + join() it before calling super.recycle(). This closes the race window entirely rather than relying on swallowing the exception.

The current AlreadyClosedBehavior.IGNORE line can be removed — it provably does nothing for openPage on 1.0.35.

Alternatives considered (and why they don't work)

• Bump io.legere:pdfiumandroid to a v1.x patch — not viable; 1.0.35 is the last v1.x and the openPage/IGNORE asymmetry was never fixed in v1.
• Bump to pdfiumandroid 2.x — not viable; openPage becomes nullable, which is source-incompatible with AndroidPdfViewer 4.0.1's compiled callsite (won't link against the prebuilt AAR).
• Catch IllegalStateException in RenderingHandler/PdfFile — would work, but those classes are in the compiled AAR, not patchable via patch-package.

Caveat: the reflection-based recycle() override should be confirmed with an actual HybridApp Android build + a navigate-away-during-render repro before merging.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/93839) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-17 16:05:08 UTC.

Proposal

What is the root cause of that problem?

Receipt PDFs enter the native PDF path through AttachmentView: when the receipt source or filename is a PDF, it renders AttachmentViewPdf, which reaches the native PDFView and mounts react-native-pdf with the receipt URL.

App/src/components/Attachments/AttachmentView/index.tsx

Lines 227 to 265 in 6ea10e7

	// Check both source and file.name since PDFs dragged into the text field
	// will appear with a source that is a blob
	const isSourcePDF = typeof source === 'string' && Str.isPDF(source);
	const isFilePDF = file && Str.isPDF(file.name ?? translate('attachmentView.unknownFilename'));
	if (!hasPDFFailedToLoad && !isUploading && (isSourcePDF || isFilePDF)) {
	const encryptedSourceUrl = isAuthTokenRequired ? addEncryptedAuthTokenToURL(source as string, encryptedAuthToken) : (source as string);
	const onPDFLoadComplete = (path: string) => {
	const id = transaction?.transactionID ?? reportActionID;
	if (path && id) {
	addCachedPDFPaths(id, path);
	}
	if (!loadComplete) {
	setLoadComplete(true);
	}
	};
	const onPDFLoadError = () => {
	setHasPDFFailedToLoad(true);
	onPDFLoadErrorProp();
	};
	// We need the following View component on android native
	// So that the event will propagate properly and
	// the Password protected preview will be shown for pdf attachment we are about to send.
	return (
	<View style={[styles.flex1, styles.attachmentCarouselContainer]}>
	<AttachmentViewPdf
	file={file}
	isFocused={isFocused}
	encryptedSourceUrl={encryptedSourceUrl}
	onPress={onPress}
	onToggleKeyboard={onToggleKeyboard}
	onLoadComplete={onPDFLoadComplete}
	style={isUsedInAttachmentModal ? styles.imageModalPDF : styles.flex1}
	isUsedAsChatAttachment={isUsedAsChatAttachment}
	onLoadError={onPDFLoadError}
	rotation={rotation}
	/>

App/src/components/PDFView/index.native.tsx

Lines 181 to 199 in 6ea10e7

	{shouldAttemptPDFLoad && (
	<PDF
	fitPolicy={0}
	trustAllCerts={false}
	renderActivityIndicator={() => (
	<LoadingIndicator
	style={loadingIndicatorStyles}
	reasonAttributes={reasonAttributes}
	/>
	)}
	source={{uri: sourceURL, cache: true, expiration: 864000}}
	style={pdfStyles}
	onError={handleFailureToLoadPDF}
	password={password}
	onLoadComplete={finishPDFLoad}
	onPageSingleTap={onPress}
	onScaleChanged={onScaleChanged}
	onPressLink={handlePressLink}
	/>

On Android, the patched react-native-pdf dependency still uses com.github.zacharee:AndroidPdfViewer:4.0.1 and io.legere:pdfiumandroid:1.0.35.

App/patches/react-native-pdf/react-native-pdf+7.0.2+001+fix-onPressLink-android.patch

Lines 5 to 10 in 6ea10e7

	@@ -143,6 +143,6 @@ dependencies {
	// The repo from zacharee is based on PdfiumAndroidKt, a much newer fork of PdfiumAndroid, with better maintenance and updated native libraries.
	implementation 'com.github.zacharee:AndroidPdfViewer:4.0.1'
	// Depend on PdfiumAndroidKt directly so this can be updated independently of AndroidPdfViewer as updates are provided.
	- implementation 'io.legere:pdfiumandroid:1.0.32'
	+ implementation 'io.legere:pdfiumandroid:1.0.35'

The race is below the React component. AndroidPdfViewer starts a PDF renderer handler thread, and PDFView.recycle() stops future render messages, then disposes pdfFile, but it cannot interrupt a render task already running inside RenderingHandler.proceed().

https://github.com/zacharee/AndroidPdfViewer/blob/da4033ed047c937c5bee3149005d25f4851372b6/android-pdf-viewer/src/main/java/com/github/barteksc/pdfviewer/PDFView.java#L465-L499

https://github.com/zacharee/AndroidPdfViewer/blob/da4033ed047c937c5bee3149005d25f4851372b6/android-pdf-viewer/src/main/java/com/github/barteksc/pdfviewer/RenderingHandler.java#L63-L86

That stale task continues through pdfFile.renderPageBitmap() into PdfiumCore.renderPageBitmap(), which calls pdfDocument.openPage(pageIndex). PdfDocument.openPage() still uses check(!isClosed) { "Already closed" }, so the existing App patch that sets AlreadyClosedBehavior.IGNORE only covers methods that call handleAlreadyClosed(); it does not cover this openPage() path.

https://github.com/zacharee/AndroidPdfViewer/blob/da4033ed047c937c5bee3149005d25f4851372b6/android-pdf-viewer/src/main/java/com/github/barteksc/pdfviewer/RenderingHandler.java#L91-L109

https://github.com/johngray1965/PdfiumAndroidKt/blob/7714b5d5356eb334b6fb10a44cad2a649d6c4568/pdfiumandroid/src/main/java/io/legere/pdfiumandroid/PdfiumCore.kt#L282-L296

https://github.com/johngray1965/PdfiumAndroidKt/blob/7714b5d5356eb334b6fb10a44cad2a649d6c4568/pdfiumandroid/src/main/java/io/legere/pdfiumandroid/PdfDocument.kt#L142-L156

App/patches/react-native-pdf/react-native-pdf+7.0.2+002+fix-pdf-crash-already-closed-android.patch

Lines 17 to 22 in 6ea10e7

	@@ -91,6 +96,7 @@ public class PdfView extends PDFView implements OnPageChangeListener,OnLoadCompl
	public PdfView(Context context, AttributeSet set){
	super(context, set);
	+ ConfigKt.setPdfiumConfig(new Config(new DefaultLogger(), AlreadyClosedBehavior.IGNORE));
	}

So when a receipt PDF view is recycled while a bitmap render is already in flight, PdfDocument.openPage() throws IllegalStateException("Already closed"); RenderingHandler catches only PageRenderingException, so the exception escapes on the renderer thread and matches the Sentry stack.

What changes do you think we should make in order to solve the problem?

Patch the Android PDF dependency path, not the receipt screen timing.

1. Keep the existing react-native-pdf patch that sets AlreadyClosedBehavior.IGNORE, because it still protects close-after-close paths that use handleAlreadyClosed().
2. Add a new patches/react-native-pdf entry that points AndroidPdfViewer to a patched 4.0.1-compatible artifact/fork, or otherwise applies the same source changes before Gradle resolves com.github.zacharee:AndroidPdfViewer.
3. In that AndroidPdfViewer patch, make PDFView.recycle() mark the view as recycled/stopped before disposing pdfFile, and make RenderingHandler.proceed() return without rendering when rendering has stopped, the view is recycled, or the current pdfFile is gone.
4. Wrap the openPage() / renderPageBitmap() render-task body so IllegalStateException("Already closed") is treated as stale work only after recycle/stop, with the allocated bitmap recycled and no page-error callback. Other active-view rendering failures should still go through the existing PageRenderingException / onPageError path.
5. Update patches/react-native-pdf/details.md to document that the older AlreadyClosedBehavior.IGNORE patch is insufficient for PdfDocument.openPage() because that method uses a direct closed-document check.

Scope boundaries: files touched should be limited to patches/react-native-pdf/* and, if needed, the Gradle dependency line inside the react-native-pdf patch. Platforms affected are Android native / Android HybridApp PDF rendering. This should cover transaction receipt PDFs and other native PDF attachments that share react-native-pdf; it should not touch web react-fast-pdf, iOS PDF rendering, image receipts, eReceipts, receipt Onyx/action code, or backend/API behavior.

What alternative solutions did you explore? (Optional)

Adding delays, earlier React unmounts, or navigation guards in src/components/PDFView/index.native.tsx would only reduce how often the race happens. They cannot stop a native render task that is already executing on AndroidPdfViewer's handler thread.

Upgrading only to AndroidPdfViewer 4.0.2 / 4.0.3 is not enough; their RenderingHandler still has the same proceed() / renderPageBitmap() flow and only catches PageRenderingException. Swallowing every IllegalStateException from PDF rendering would be too broad, because active-view rendering errors should still surface; the ignore path should be limited to stale render work after recycle/stop.

[github-actions]

⚠️ @KJ21-ENG Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).

[KJ21-ENG]

Updated my proposal: refreshed the existing proposal with the latest L2 root cause and fix scope.