fix: reserved community type test fixes#6208
Conversation
✅ Deploy Preview for partners-bloom-dev ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for partners-bloom-msq2 canceled.
|
✅ Deploy Preview for bloom-angelopolis ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for bloom-public-seeds ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for bloom-exygy-dev ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
9625326 to
e2886ef
Compare
| // create pre-determined values | ||
| const unitTypes = await unitTypeFactoryAll(prismaClient); | ||
| // Clear all existing reserved community types and add new ones | ||
| await prismaClient.reservedCommunityTypes.deleteMany(); |
There was a problem hiding this comment.
question: I am unsure about this, in LA this is going to cause some issues (a difference between the reserved community types available with the ones created by the migrations being deleted here and the generic reserved community types created)
I think maybe we should talk about this in a bit more depth but curious if @emilyjablonski feels similarly about this difference mattering
There was a problem hiding this comment.
I could pull it over to LA to test it but my initial instinct would be that it would be ok - I think I might be missing something tho! What pieces would you expect would break?
There was a problem hiding this comment.
I don't think anything would break, but there would be differences between our local versions stood up and what LA actually has for reserved community types
There was a problem hiding this comment.
Oh I see!! Yes I agree it would be ideal that LA migrations would be reflected when seeding over there - and removing the types here would cause a mismatch
There was a problem hiding this comment.
We are still going to run into mismatches in the LA repo since we don't filter by jurisdiction on the reserved community type. The way it currently works is it will display all of the LA and all of the seeded RCTs. So for example the Senior62 will show up twice. This will continue to cause headaches for our tests in a forked repo.
I could get around the specific problem we have for LA by making the tests select community types that are not in the LA migration files. And also update which one of the seeded RCTs has a description. Would that work for everyone? We could potentially run into issues with the next jurisdiction or even LA if they change the community types they want, but it would at least save us some headaches in the near term until we can fully refactor how community types are saved and fetched.
There was a problem hiding this comment.
@YazeedLoonat @emilyjablonski Do you have any thoughts on this?
There was a problem hiding this comment.
Confirming we chatted about a generic RCT for testing that doesn't exist in prod envs!
There was a problem hiding this comment.
^ Just checking in again about the generic RCT updates but no rush
ludtkemorgan
added
the
1 review needed
3 participants
This PR addresses issue with bloom-la release.
Description
Two fixes to accommodate changes a forked jurisdiction might want and still allow tests to pass:
How Can This Be Tested/Reviewed?
All tests should still pass.
Author Checklist:
yarn generate:clientand/or created a migration when requiredReview Process: