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

Bug Fix for Transaction Read/Write Error #401

Merged
merged 16 commits into from
Feb 29, 2024
Merged

Conversation

dowhep
Copy link
Contributor

@dowhep dowhep commented Feb 11, 2024

Info

Closes [#400]. (If there is no issue for this pull request yet, please create one or
delete this line if the pull request is for a very minor tweak).

Description

What changes did you make? List all distinct problems that this PR addresses. Explain any relevant
motivation or context.

I added the asynchronous retry for repository Read/Write to greatly reduce the chance of the error showing up.

Changes

Fill in later

Type of Change

  • Patch (non-breaking change/bugfix)
  • Minor (non-breaking change which adds functionality)
  • Major (fix or feature that would cause existing functionality to not work as
    expected)
  • Documentation (A change to a README/description)
  • Continuous Integration/DevOps Change (Related to deployment steps, continuous integration
    workflows, linting, etc.)
  • Other: (Fill In)

If you've selected Patch, Minor, or Major as your change type, make sure to bump the version before merging in package.json!

Testing

I have tested that my changes fully resolve the linked issue ...

  • locally.
  • on the testing API/testing database.
  • with appropriate Postman routes. Screenshots are included below.

Checklist

  • I have performed a self-review of my own code.
  • I have followed the style guidelines of this project.
  • I have appropriately edited the API version in the package.json file.
  • My changes produce no new warnings.

Screenshots

Please include a screenshot of your Postman testing passing successfully.

Copy link

Thanks for contributing!
If you've made changes to the API's functionality, please make sure to bump the package
version—see this guide to semantic versioning for details—and
document those changes as appropriate.

@dowhep dowhep self-assigned this Feb 11, 2024
Copy link
Member

@nik-dange nik-dange left a comment

Choose a reason for hiding this comment

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

I haven't found a fix for your testing issue yet, but an additional consideration I had was to find a way to send concurrent requests in a test case to ensure this feature works. Perhaps we can try to explore Promise.all or a similar construct–can discuss this more at our next dev meeting

repositories/index.ts Show resolved Hide resolved
repositories/index.ts Outdated Show resolved Hide resolved
@@ -457,7 +457,6 @@ async function seed(): Promise<void> {
});
const MERCH_ITEM_1_PHOTO_1 = MerchFactory.fakePhoto({
merchItem: MERCH_ITEM_1,
Copy link
Member

Choose a reason for hiding this comment

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

Nit: maybe add these uploadedPhoto links back in for seeding data purposes now that you're done testing on the local frontend

Copy link
Contributor Author

Choose a reason for hiding this comment

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

To be honest, the link before was just a dummy link, and since I added the default dummy link to the MerchFactory, I think it is no longer necessary to have it here. Do you think it is better to declare it explicitly instead?

Copy link
Member

Choose a reason for hiding this comment

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

As long as there's no issues, I think it's fine to have it in the MerchFactory since it's a generic property of all merch item photos. If we do this though, maybe we should consider abstracting away any other common properties for seed data that we create. not high priority but something to keep in mind

@@ -37,10 +37,10 @@ export class EventFactory {
requiresStaff: FactoryUtils.getRandomBoolean(),
staffPointBonus: EventFactory.randomPointValue(),
committee: 'ACM',
cover: faker.internet.url(),
cover: `http://i.imgur.com/${faker.random.alphaNumeric(10)}.jpeg`,
Copy link
Member

Choose a reason for hiding this comment

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

For the sake of consistency and cleanliness, do you want to change all links to this format, or revert back to the old format? It's not a huge deal but it might be nice to keep our seeding data friendly to read, unless this is better for future local frontend testing (which likely won't rlly happen since staging will get ported to V2)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think this is worth discussing, but at the very least I should refactor this to a clean function call.

@@ -15,6 +16,9 @@ import { LeaderboardRepository } from './LeaderboardRepository';
import { ResumeRepository } from './ResumeRepository';
import { UserSocialMediaRepository } from './UserSocialMediaRepository';

const HINT_FOR_RETRIABLE_TRANSACTIONS : string = 'The transaction might succeed if retried.';
const AMOUNT_OF_RETRIES : number = 10;
Copy link
Member

Choose a reason for hiding this comment

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

are we consistent with declaring numbers like this at the top of the file or do we generally do this in the Config? small nit either way but for the sake of consistency

Copy link
Member

@nik-dange nik-dange left a comment

Choose a reason for hiding this comment

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

great work on this important feature 🫡 and nice job with the smart repository layer implementation + finding out how to run concurrent tests

@dowhep dowhep merged commit 60cba34 into master Feb 29, 2024
5 checks passed
@dowhep dowhep deleted the feature/retry-transactions branch February 29, 2024 01:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants