api-structs #117
No reviewers
Labels
No Label
Compat/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
Activity:Doing
Activity:Proposal
Runner
AT
Runner
CLI
Runner
HTTP
cleanup
devops
easypeasy
exchange
legacy
optimization
privilege
refactor
smell
support
ux
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: urdt/ussd#117
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "api-structs"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Introduces new api structs that communicate with the local development setup
WIP: api-structsto api-structs@ -11,2 +12,4 @@
"github.com/grassrootseconomics/eth-custodial/pkg/api"
)
type ApiResponse struct {
why is this needed?
Well,at the point of making the api call and receiving a response back, we don't really know the response that will be sent back,it can either be an ErrResponse or an OKResponse but we are certain that the ok and description field will be present.So the OK field in the ApiResponse will be used to decide which type to Unmarshal on.
@ -53,0 +65,4 @@
var okResponse api.OKResponse
var err error
// Construct the URL with the path parameter
url := fmt.Sprintf("%s/%s", config.TrackURL, publicKey)
I think it is better and safer to use the
net/url
package for handling urls?I will add it as a separate issue.
#125
@ -140,0 +144,4 @@
flag_api_call_error, _ := h.flagManager.GetFlag("flag_api_call_error")
okResponse, errResponse := h.accountService.CreateAccount()
if errResponse != nil {
if !errResponse.Ok {
When is an error response "ok"?
If unknown, perhaps @kamikazechaser can clear it up
In the menu handler's context,we needed a way to decide which error from calling the CreateAccountService we could use to set the flag 'flag_api_call_error' and because an error could occur when calling the CreateAccount that's not associated with an api call,say maybe Unmarshaling,then checking if the Ok field is present and is false is what i considered as an api call failure.
@ -53,0 +93,4 @@
}
return nil, errors.New(errResponse.Description)
}
if len(okResponse.Result) == EMPTY_RESPONSE {
I would just use the literal
0
hereIf there is no matching tracking id, result.otx will be null.
@kamikazechaser please elaborate is there a missing case?
@ -53,0 +79,4 @@
return nil, err
}
defer resp.Body.Close()
Check the HTTP response code first. If it is >= 400 (Bad request you can then unmarshal to an api.ErrResp.