Skip to content

Edge Case where one review may be overwritten by another (presubmission) #212

@lwasser

Description

@lwasser

In working with calculating review metrics for our org, i encountered a scenario where

  1. there is a presubmission called packagename
  2. there is then a submission called packagename

Because as we collect issues we create model objects in a dict that looks like this:

packagename: model-here we run the risk of a submission's data being overwritten by a presubmission and vice versa.

this is because if a request provides more than one label, the rest api (i think) requires you to process all labels. we'd have to use graphql (i could be wrong) to parse specific labels.

there are few options here i think.

  1. if the user requests issues that have one of multiple labels we could potentiall create a loop type approach (that would be complex given how we've generated the endpoint i think?
  2. we could search teh dict keys - if the package name already exists, we can just add a new key that has an underscore so the data don't get overwritten .

the second is also problematic because we use that dict key as the key in our yaml file for the website.

i'm not actually sure what the best approach is here but i wanted to raise this as an edge case!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions