swagger-api / swagger-api/swagger-codegen

[Andoird][Volley] 403 response code not being caught in ErrorResponse

Open
#8,007 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Mustache
Stars
17.8k
Forks
6k
PR merge metrics
No merged PRs in 30d

Description

Description

Server sending 403 upon a certain logic that I have, but I'm not able to catch that error in the error listener. The server sends the 403, and never sends it again. If I force my server to send 403 more than once, it works and I am able to catch the error, but sending it the first time prompts a retry in the function call. The format that I'm using is the following

DeafultAPI.myApiFunction(myBody, response -> {
  // if success
}, error -> {
  // if error. I want to be able to see the 403 error here from the first time
})
Swagger-codegen version

I was on v2.2.2, I updated from master (using maven to build it) an hour ago, so v2.4.0

Swagger declaration file content or url

...

Command line used for generation
java -jar modules/swagger-codegen-cli/target/swagger-codegen-cli.jar generate -i ~/PATH_TO_YAML.yaml -l android --library=volley -o ~/andoird_sdk
Steps to reproduce

Have the server send 403 only once for a certain API and try to catch it in the error callback

Related issues/PRs

A PR has been approved for retrofit library, so I think it's a default behavior?
https://github.com/swagger-api/swagger-codegen/pull/6290

Suggest a fix/enhancement

Is there a value I can set to disallow retrying, or if there's something I can do to allow 403 errors to be passed in the error callback?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the generated Android client's Volley request and error-callback path, using the provided generation command to reproduce the client. Trace the first 403 response and subsequent retry behavior; done means a single 403 reaches the supplied error callback, with relevant behavior covered by a regression test if the project has one.

Written by the indexing model from the issue text.

Assessment

Tech stack
android, java
Domain
mobile
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.