Split out from #1497 — Swift executor URLSession error audit. Section D — Crash instead of classified error.
File references are to native/swift/Sources/wordpress-api/SafeRequestExecutor.swift unless noted; :NNN line numbers were verified against fix/converge-executor-error-classification.
Severity: low. After the session owner calls invalidateAndCancel, the next execute()/upload() calls session.dataTask/uploadTask on the invalidated session, which raises Foundation's "task created in a session that has been invalidated" NSException — uncatchable from Swift. Requires caller misuse; worth a doc note that the injected URLSession must outlive the executor (or track didBecomeInvalidWithError and fail fast with GenericError). Incidentally, this lens confirmed the .cancelled → CancellationError mapping is honest: the library's own two cancel paths and an in-flight invalidateAndCancel all funnel there, and the challenge handler never returns .cancelAuthenticationChallenge, so no non-cancellation source of .cancelled exists in this executor. ✅
Severity: low. After the session owner calls
invalidateAndCancel, the nextexecute()/upload()callssession.dataTask/uploadTaskon the invalidated session, which raises Foundation's "task created in a session that has been invalidated" NSException — uncatchable from Swift. Requires caller misuse; worth a doc note that the injectedURLSessionmust outlive the executor (or trackdidBecomeInvalidWithErrorand fail fast withGenericError). Incidentally, this lens confirmed the.cancelled → CancellationErrormapping is honest: the library's own two cancel paths and an in-flightinvalidateAndCancelall funnel there, and the challenge handler never returns.cancelAuthenticationChallenge, so no non-cancellation source of.cancelledexists in this executor. ✅