Repository navigation
Conversation
`batch verify` gains a --simulate flag forwarding the documented test-key-only error-simulation parameter (generic_error, insufficient_credits_error, payment_error, card_error), so error handling can be exercised without real verifications. The documented captcha_response parameter stays unexposed by design — it only applies to public API keys in client-side CAPTCHA flows, not a secret-key CLI — with a code comment recording why.
There was a problem hiding this comment.
Pull request overview
Adds support for simulating documented test-key-only API errors when submitting batch verifications, enabling local exercising of CLI error handling without performing real verifications.
Changes:
- Add
Simulatetoapi.SubmitBatchOptionsand forward it assimulatein the batch submission form body. - Expose
--simulateonemailable batch verifyand thread it into submission options. - Add an e2e test ensuring
--simulateis forwarded; add a comment explaining whycaptcha_responseremains intentionally unexposed forverify.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| internal/api/client.go | Adds Simulate option and forwards simulate parameter in batch submission POST body. |
| cmd/verify.go | Adds a clarifying comment about intentionally not exposing captcha_response. |
| cmd/batch.go | Adds --simulate flag and wires it into SubmitBatchOptions. |
| cmd/batch_e2e_test.go | Adds an e2e test asserting --simulate is included in the submit form body. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+221
to
+227
| if cmd.Flags().Changed("simulate") { | ||
| v, err := cmd.Flags().GetString("simulate") | ||
| if err != nil { | ||
| return nil, err | ||
| } | ||
| opts.Simulate = v | ||
| any = true |
Comment on lines
+81
to
+84
| // The documented `captcha_response` parameter is intentionally not exposed: | ||
| // it only applies to public API keys behind a CAPTCHA challenge in | ||
| // client-side (browser/mobile) flows. The CLI authenticates with a secret | ||
| // key, where CAPTCHA never applies, so a flag for it would be dead weight. |
Member
Author
|
Closing — |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
batch verifygains a--simulateflag forwarding the documented test-key-only error-simulation parameter (generic_error,insufficient_credits_error,payment_error,card_error), so error handling can be exercised without real verifications.The documented
captcha_responseparameter stays unexposed by design — it only applies to public API keys in client-side CAPTCHA flows, not a secret-key CLI — with a code comment recording why.