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

Incorporate error handling in a few places #16

Merged
merged 4 commits into from
Dec 12, 2024

Conversation

rnathuji
Copy link
Contributor

No description provided.

@rnathuji rnathuji force-pushed the SHRMP-52/error-handling branch from 725cfe8 to d87b3bc Compare December 11, 2024 22:26
@@ -55,4 +95,27 @@ describe('POST /api/run/[runId]/upload', () => {
const response = await POST(req, { params })
expect(response.status).toBe(400)
})

it('should return an error if the runID has results already', async () => {
Copy link
Collaborator

Choose a reason for hiding this comment

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

one "product" question i have around this is

  1. will they ever be uploading results for the same run? ie runs will always have different uuids right? so this is just a safeguard
  2. if the above is true, ie they can upload results for the same run, would we want to override and upload the newer results? ie overwrite vs error

just thinking out loud 🤔 💭

Copy link
Contributor Author

@rnathuji rnathuji Dec 12, 2024

Choose a reason for hiding this comment

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

Ah, I see. Yeah, my implicit assumption currently is it's a safeguard in case the researcher code (for some reason that was missed during code review 😅 ) attempts to submit multiple times for the same run.

I guess another case it could protect against is if (for whatever reason) the SA runs things twice, we ignore the erroneous re-submit.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

🤔 -- FWIW, I think if we allow "override", we should version artifacts vs write over. That would definitely require some product definition, though, since it would have cascading impacts 😅 .

Copy link
Collaborator

Choose a reason for hiding this comment

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

yeah with your 2nd comment in mind, happy to just reject it and enforce a new runid upload :)


const response = await POST(req, { params })
expect(response.status).toBe(400)
expect((await response.json()).error).toBe('Data already exists for runId')
Copy link
Collaborator

Choose a reason for hiding this comment

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

@philschatz had left a comment on my PR about testing for the error string of the 400 response and maybe having that not be necessary? im not sure if that applies here - i dont feel strongly either way, just pointing out for consistency

Copy link
Contributor Author

@rnathuji rnathuji Dec 12, 2024

Choose a reason for hiding this comment

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

Yeah -- I added it only to make sure we are getting the 400 from the expected code paths (because it can otherwise lead to false positive test passes). I'm open to a better suggestion on how to accomplish that, though 🤷‍♂️

Copy link
Collaborator

Choose a reason for hiding this comment

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

oh yeah good point! Im happy keeping it in, doesn't matter much to me

Copy link
Collaborator

@chrisbendel chrisbendel left a comment

Choose a reason for hiding this comment

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

looks good just some cosmetic and philosophical questions 🤣

@rnathuji rnathuji merged commit 2325b36 into SHRMP-48-code-coverage Dec 12, 2024
@rnathuji rnathuji deleted the SHRMP-52/error-handling branch December 12, 2024 17:09
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