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?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
