Skip to content

Comments

Revise Docupipe plan with concrete endpoint workflow#2

Open
matthewdavidian wants to merge 3 commits intomasterfrom
codex/plan-integration-for-docupipe-api
Open

Revise Docupipe plan with concrete endpoint workflow#2
matthewdavidian wants to merge 3 commits intomasterfrom
codex/plan-integration-for-docupipe-api

Conversation

@matthewdavidian
Copy link
Contributor

Motivation

  • The previous Docupipe plan was high-level and needed concrete endpoint behavior to guide implementation and testing.
  • Provide an async-first, orchestration-focused design that returns raw DocuPipe JSON and leaves schema selection and polling cadence to the application.
  • Capture required headers, retry semantics, and practical constraints (URL vs multipart upload) so implementers have clear trade-offs.

Description

  • Updated docs/docupipe_integration_plan.md with explicit DocuPipe endpoints (POST /document, GET /document/{id}, POST /v2/standardize/batch, GET /job/{id}, GET /standardization/{id}) and auth/header conventions (X-API-Key, JSON headers).
  • Proposed package layout and class names including cDocuPipeClient, cDocuPipeDocumentService, cDocuPipeStandardizationService, cDocuPipeJobService, and docupipeai.h with minimal tDocuPipe* structs that pass through raw JSON and surface orchestration IDs/statuses.
  • Defined public async API signatures (e.g., SubmitDocumentFromFile, SubmitDocumentFromUrl, Standardize, GetJob, GetStandardization), a single-retry-on-transient policy, and logging/diagnostics hooks.
  • Added phased implementation and verification plan covering client shell, endpoint wiring, parsing/ergonomics, and mocked/integration tests.

Testing

  • No automated tests were added or executed for this documentation-only change.
  • The updated plan file was reviewed and written to docs/docupipe_integration_plan.md for implementers to follow when adding unit and integration tests in later phases.
  • Planned verification includes mocked-response unit tests for submit -> documentId, standardize -> jobId, and job status transitions, plus integration tests with sample documents as described in the plan.

Codex Task

Copy link

@chatgpt-codex-connector chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7f0fb59bd2

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment on lines +114 to +118
- Retry exactly once on:
- transport/network failure
- HTTP 429
- HTTP 5xx
- Do not retry on 4xx except 429.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Avoid retrying non-idempotent DocuPipe POST operations

The retry policy currently applies a blind retry to transport failures/429/5xx across the board, which will also hit POST /document and POST /v2/standardize/batch. If the first POST succeeded server-side but the response was lost (timeout/network drop), retrying can create duplicate documents/jobs and corrupt downstream queue state or billing counts. Please scope automatic retries to idempotent reads or require an idempotency key/deduplication strategy for submit/standardize writes.

Useful? React with 👍 / 👎.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant