[
https://issues.apache.org/jira/browse/TIKA-4808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18105220#comment-18105220
]
ASF GitHub Bot commented on TIKA-4808:
--------------------------------------
dpol1 commented on PR #3028:
URL: https://github.com/apache/tika/pull/3028#issuecomment-5313970084
oh nice - this is the seam I was faking on the 4795 branch with a spool file
and a fake fetcher. with this in core I can drop that bridge entirely and the
ticket gets to be about the thing that actually matters: same bytes, parse
profile and semantic hints -> same canonical Document, whichever door the bytes
come in through. thanks for the cc - I'll rebase onto this once it lands.
three small edges flagged by claude:
- `maxInlineBytes`/`maxIpcPayloadBytes`: the pair check lives in the setter,
so lowering only `maxIpcPayloadBytes` (say 5m) leaves the 10m inline default
unvalidated, and `{inline: 95m, ipc: 200m}` passes or fails depending on json
key order. could the pair be checked after deserialization? server and grpc
deserialize `PipesConfig` directly, so `load()` alone wouldn't cover them.
- `PayloadRouter.route()`: if the source throws after the spool file is
created, no `Routed` exists yet, so nobody deletes the partial file - I
reproduced a leftover this way.
- `PipesForkParser.parse()`: the inline body goes into the caller's
ParseContext and is never restored, so a later file-backed parse retains and
re-serializes the old body. should it be restored in `finally`, making the
payload request-owned?
> Prepare for 4.0.0 release
> -------------------------
>
> Key: TIKA-4808
> URL: https://issues.apache.org/jira/browse/TIKA-4808
> Project: Tika
> Issue Type: Task
> Reporter: Tim Allison
> Priority: Major
> Attachments: reports-4.0.0b-1.zip, reports-4.0.0b-reports.tgz
>
>
> I think we're good to go. Let me know if there are any blockers.
> I'll kick off the regression tests shortly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
