Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(backend): incoming payment action resolvers #2865

Conversation

BlairCurrey
Copy link
Contributor

@BlairCurrey BlairCurrey commented Aug 15, 2024

Changes proposed in this pull request

  • fixes graphql resolvers/bruno requests

Context

Checklist

  • Related issues linked using fixes #number
  • Tests added/updated
  • Documentation added
  • Make sure that all checks pass
  • Bruno collection updated

golobitch and others added 16 commits July 30, 2024 23:18
This change will add two new table columns in the incomingPayments table on the backend service. ASE
will be able to call cancel or approve incoming payment GraphQL API, and the timestamp of the call
will be save in the database under these two fields. Normally, both of these two fields are
optional.
This commit introduces possibility, to approve incoming payment through Admin API. API can be called
with existing incoming payment as ID. Rafiki will fetch the incoming payment and update it's
approvedAt field in the database. In case that payment does not exists or that it is not in the
PENDING state, appropriate error is returned.

#2811
It will be possible to cancel incoming payment due to some requirements. Rafiki just need to get a
call to cancel incoming payment, with the payment ID. If transaction is in PENDING state and it is
in the database, then it will get updated. It's cancelledAt field will be set  to current time.

#2811
…ing payments

Introduced three new env variables that will set the behaviour of actionable incoming payments. One
env variable will define if polling will be done, meaning that it will wait for the incoming payment
to be accepted or rejected, and other two env variables defines timeout for polling and polling
frequency
Our builds are failing due to Trivy scanner. Trivy scanner actually found that our Axios version
v1.6.8 has a vulnerability - CVE-2024-39338. This was fixed in version 1.7.4, hence, the upgrade.

fix #2860
@github-actions github-actions bot added type: tests Testing related pkg: backend Changes in the backend package. pkg: frontend Changes in the frontend package. type: source Changes business logic pkg: mock-ase pkg: mock-account-service-lib labels Aug 15, 2024
Base automatically changed from feature/2811-actionable-incoming-payments to main August 21, 2024 15:07
@mkurapov
Copy link
Contributor

@BlairCurrey can we close this?

@golobitch
Copy link
Collaborator

@BlairCurrey can we close this?

I think we can yes. @BlairCurrey helped me a lot with the review of Actionable incoming payments, and I had a mess in Bruno files, so Blair helped and fixed that. Since we already merged actionable incoming payments, yes, we can probably close this.

@BlairCurrey
Copy link
Contributor Author

Yeah it was some suggestions from the PR that has already been merged. Not needed now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pkg: backend Changes in the backend package. pkg: frontend Changes in the frontend package. pkg: mock-account-service-lib pkg: mock-ase type: source Changes business logic type: tests Testing related
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants