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: remove and resolve FIXMEs and TODOs from db module #174

Merged
merged 9 commits into from
Dec 20, 2022
Merged

Conversation

NishantJoshi00
Copy link
Member

Type of Change

  • Enhancement

Description

This change addresses todo!() in the MockDb interface implementation and group them under issue #172 . It fixes and removes other FIXMEs from the db folder.

Additional Changes

  • This PR modifies the database schema
  • This PR modifies application configuration/environment variables

Motivation and Context

Following the initiative of removing TODOs and FIXMEs.
Linked issues:

How did you test it?

Checklist

  • I formatted the code cargo +nightly fmt
  • I addressed lints thrown by cargo clippy
  • I reviewed submitted code

@NishantJoshi00 NishantJoshi00 added A-core Area: Core flows S-waiting-on-author Status: This PR is incomplete or needs to address review comments S-waiting-on-review Status: This PR has been implemented and needs to be reviewed C-refactor Category: Refactor labels Dec 19, 2022
@NishantJoshi00 NishantJoshi00 self-assigned this Dec 19, 2022
@NishantJoshi00 NishantJoshi00 removed the S-waiting-on-author Status: This PR is incomplete or needs to address review comments label Dec 19, 2022
jarnura
jarnura previously approved these changes Dec 19, 2022
@jarnura jarnura added S-awaiting-merge S-needs-conflict-resolution Status: This PR needs conflicts to be resolved by the author and removed S-waiting-on-review Status: This PR has been implemented and needs to be reviewed S-awaiting-merge labels Dec 19, 2022
@@ -340,10 +346,9 @@ mod storage {
"{}_{}",
payment_attempt.payment_id, payment_attempt.merchant_id
);
// TODO: need to add an application generated payment attempt id to distinguish between multiple attempts for the same payment id
// Check for database presence as well Maybe use a read replica here ?
Copy link
Member

Choose a reason for hiding this comment

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

Are you sure this is not required either?

Copy link
Member Author

Choose a reason for hiding this comment

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

It's fixed, below.

Copy link
Member

Choose a reason for hiding this comment

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

I'm referring to this comment:

Check for database presence as well [...]

Copy link
Member Author

Choose a reason for hiding this comment

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

I'll check it out, I also feel it's an actionable

Copy link
Member Author

@NishantJoshi00 NishantJoshi00 Dec 19, 2022

Choose a reason for hiding this comment

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

I have done the change, please take a look and suggest improvement, if any.

Copy link
Member

Choose a reason for hiding this comment

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

need to add an application generated payment attempt id to distinguish between multiple attempts for the same payment id

Now that I re-read this comment, I don't think we're determining multiple attempts to the same payment ID in our code, are we?

Looks like we're just setting the attempt_id to be an UUID here:
https://github.com/juspay/orca/blob/03d0cb1f5e256da6973932f388bab8d9e758bda6/crates/router/src/core/payments/operations/payment_create.rs#L437

Copy link
Member Author

Choose a reason for hiding this comment

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

This comment was regarding how it is being saved in the kv, previously it was only marked as pa, but later it was modified to be pa_{} in the redis hashmap

Copy link
Member Author

Choose a reason for hiding this comment

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

But, yes! Currently we only have one-to-one mapping between payment_intent and payment_attempt

Copy link
Member

Choose a reason for hiding this comment

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

This comment was regarding how it is being saved in the kv, previously it was only marked as pa, but later it was modified to be pa_{} in the redis hashmap

Ahh right, my bad, I misinterpreted it.

Copy link
Contributor

Choose a reason for hiding this comment

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

TODO: need to add an application generated payment attempt id to distinguish between multiple attempts for the same payment id

is this talking about adding attempt id to the key?

@NishantJoshi00 NishantJoshi00 added the S-in-progress Status: Implementation is underway label Dec 19, 2022
@NishantJoshi00 NishantJoshi00 added S-waiting-on-review Status: This PR has been implemented and needs to be reviewed and removed S-in-progress Status: Implementation is underway S-needs-conflict-resolution Status: This PR needs conflicts to be resolved by the author labels Dec 19, 2022
@ashokkjag
Copy link
Contributor

can be remove the allow_panics too?

crates/router/src/db/queue.rs Outdated Show resolved Hide resolved
crates/router/src/db/queue.rs Outdated Show resolved Hide resolved
@@ -340,10 +346,9 @@ mod storage {
"{}_{}",
payment_attempt.payment_id, payment_attempt.merchant_id
);
// TODO: need to add an application generated payment attempt id to distinguish between multiple attempts for the same payment id
// Check for database presence as well Maybe use a read replica here ?
Copy link
Contributor

Choose a reason for hiding this comment

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

TODO: need to add an application generated payment attempt id to distinguish between multiple attempts for the same payment id

is this talking about adding attempt id to the key?

@NishantJoshi00
Copy link
Member Author

Hey @ashokkjag, this comment is regarding the field value used to store the payment attempt in the hash map, earlier it was stored as "pa" but in case of multiple payment attempt this would fail. That was the intent of the comment, but it seems someone already solved it before this PR.

@jarnura jarnura added S-awaiting-merge and removed S-waiting-on-review Status: This PR has been implemented and needs to be reviewed labels Dec 20, 2022
@jarnura jarnura merged commit 76b47e6 into main Dec 20, 2022
@jarnura jarnura deleted the db-fixmes branch December 20, 2022 12:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-core Area: Core flows C-refactor Category: Refactor
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants