Add optional PDF and image attachments to extract.ai#1179
Conversation
Co-authored-by: ebhills <53243273+ebhills@users.noreply.github.com>
Co-authored-by: ebhills <53243273+ebhills@users.noreply.github.com>
Co-authored-by: ebhills <53243273+ebhills@users.noreply.github.com>
|
@copilot - Can we wire in s3 (using our connector and/or boto) so that we can reference remote files? |
Co-authored-by: ebhills <53243273+ebhills@users.noreply.github.com>
Co-authored-by: ebhills <53243273+ebhills@users.noreply.github.com>
Implemented in Use Checks: 318 focused tests, 1,896 local-suite tests, package builds, and secret scans passed; CodeQL found 0 alerts. Final targeted review found no significant issues; the automated review binary was unavailable. Live S3/OpenAI validation remains outstanding. Recommended disposition: Comment only Next steps
|
Linked issue
What changes
Allow
extract.aito extract directly from PDFs and images, optionally combined with text, without Markdown conversion. This slice supports explicit local files through OpenAI Responses.How it was verified
Compatibility and risk
Text-only behavior, return shapes, schemas, and configuration precedence remain unchanged. Attachments require a vision-capable structured-output Responses model; URLs, raw bytes, provider file IDs, and Chat Completions are unsupported.
Files are sent inline—no separate upload lifecycle. Existing
store: truedefaults apply. Visual requests can require larger timeouts/output budgets and lower concurrency. Source references remain model-generated claims requiring validation.Rollback: omit
attachmentsto restore text-only calls, or revert the change.Ready-for-review checklist
mainand has no merge conflictsSee the pull request workflow.