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

feat!: update tx segment element with updated cool-seq-tool structure changes #314

Merged
merged 19 commits into from
Aug 27, 2024

Conversation

katiestahl
Copy link
Contributor

@katiestahl katiestahl commented Aug 12, 2024

  • update naming of functions + variables
  • no more strand passed into tx segment element functions
  • changed GenomicData -> GenomicTxSegService
  • updated usage of Assayed/Categorical FusionElement in accordance with recent fusor change
  • updated tests - a lot of these are failing from weird asyncio issues, not sure if that was pre-existing or if I have stuff set up weirdly locally. I'm still looking into this, but from testing the app, everything looks like it's functioning correctly? Other than transcript segment element with using transcript/genomic coordinates. This appears to have broken either from the last PR or was already broken. This will be resolved when I finally get to resume feat: add transcript lookup for genes #273

Going to leave this in a draft for now, so I don't accidentally merge it before we have new CST and fusor releases with the changes that this PR implements

Close #272

@katiestahl katiestahl added priority:high High priority build Changes that affect the build system or dependencies labels Aug 12, 2024
@katiestahl katiestahl self-assigned this Aug 12, 2024
Copy link

This PR is stale because it has been open 1 day(s) with no activity. Please review this PR.

@github-actions github-actions bot added the stale label Aug 14, 2024
@korikuzma korikuzma removed the stale label Aug 20, 2024
@katiestahl katiestahl marked this pull request as ready for review August 22, 2024 18:08
}
},
check_coords_response,
)

await check_response(
"/api/utilities/get_exon?chromosome=1",
Copy link
Contributor Author

Choose a reason for hiding this comment

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

we no longer support numbers for chromosomes, as far as I can tell. I think this is fine for now, especially since there's nowhere a user types in a chromosome (it's always auto-populated and unable to be edited)

await check_validated_fusion_response(
async_client, ewsr1_fusion_fill_types, "EWSR1 fusion needing type inference"
)
# await check_validated_fusion_response(
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 would like some opinions/eyes on this. I think because of the change I made in cancervariants/fusor#174, we can't do inference to the extent of before. Is this a problem? Is it okay to leave for now and make an issue for improvement later?

Copy link
Member

Choose a reason for hiding this comment

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

Looking at this now

Copy link
Member

Choose a reason for hiding this comment

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

How often does this happen in the UI where a user is going through the form and no type is provided?

Copy link
Member

Choose a reason for hiding this comment

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

I think we can save this for a new issue IMO. I think we'd just need to add a model_validator to AssayedFusion for this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

it's currently not possible to get to this state without a provided fusion type. The UI always adds the type in the request before calling the validation function

@jsstevenson
Copy link
Member

tests failing is a preexisting issue: #303

@katiestahl
Copy link
Contributor Author

tests failing is a preexisting issue: #303

oh oop, should I remove that part of this PR?

@jsstevenson
Copy link
Member

oh oop, should I remove that part of this PR?

Oh if you've fixed stuff I think it's fine to package in. I was just saying that some of those tests were already failing so it shouldn't hold back this PR if everything else seems ok

jsstevenson
jsstevenson previously approved these changes Aug 22, 2024
Copy link
Member

@jsstevenson jsstevenson left a comment

Choose a reason for hiding this comment

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

👍

@korikuzma
Copy link
Member

@jarbesfeld Are you able to review this?

@jarbesfeld
Copy link

@korikuzma Yes I can test UI as well

jarbesfeld
jarbesfeld previously approved these changes Aug 23, 2024
Copy link

@jarbesfeld jarbesfeld left a comment

Choose a reason for hiding this comment

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

Nice work! See comment in conftest.py for a suggestion on how to improve one of the tests

@korikuzma korikuzma dismissed stale reviews from jarbesfeld and jsstevenson via 09e10bd August 23, 2024 13:12
Comment on lines -167 to +179
"exonStartOffset": 5,
"exonStartOffset": 72,
"exonEnd": 6,
"exonEndOffset": -71,
"gene": tpm3_descriptor,
"exonEndOffset": -5,
"gene": tpm3_gene,

Choose a reason for hiding this comment

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

This example is technically correct, but it results in a Transcript Segment with only one nucleotide. I'd recommend in a different PR changing exonStart and exonEnd to be different values

Choose a reason for hiding this comment

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

I'm going to make a separate issue for this since this is technically correct

@korikuzma
Copy link
Member

Screenshot 2024-08-23 at 10 22 22

@katiestahl another issue that should be resolved is Transcript Segment Element needs either start or end to be valid. This is requiring start and end at the moment.

I'm also having more state issues. I fill out everything in structure, domain, reading frame, and look at summary. Once I go back to structure, I remove ending position but it still saves in the summary.

@katiestahl
Copy link
Contributor Author

Screenshot 2024-08-23 at 10 22 22 @katiestahl another issue that should be resolved is Transcript Segment Element needs either start or end to be valid. This is requiring start and end at the moment.

I'm also having more state issues. I fill out everything in structure, domain, reading frame, and look at summary. Once I go back to structure, I remove ending position but it still saves in the summary.

on it!

@katiestahl
Copy link
Contributor Author

Screenshot 2024-08-23 at 10 22 22 @katiestahl another issue that should be resolved is Transcript Segment Element needs either start or end to be valid. This is requiring start and end at the moment. I'm also having more state issues. I fill out everything in structure, domain, reading frame, and look at summary. Once I go back to structure, I remove ending position but it still saves in the summary.

on it!

so I am still trying to figure out why this is behaving like this. It looks like for the first TX Segment element, it's always invalid if it has a start (but it's fine if it has a start and end or only an end)

…ther a start or end now, regardless of position in the structure
: index === 0
? txEndingGenomic || endingExon
: txStartingGenomic || startingExon;
txEndingGenomic || endingExon || txStartingGenomic || startingExon;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

please double check me on this change! From my understanding, based on the sequence location changes, a Tx segment element only requires either a start/end, regardless of position (it looks like previously, it had to have both unless it was the first item?)

Copy link

@jarbesfeld jarbesfeld Aug 23, 2024

Choose a reason for hiding this comment

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

Yes only one of start/end is required to create a TranscriptSegmentElement

Copy link
Member

@korikuzma korikuzma left a comment

Choose a reason for hiding this comment

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

The structure tab says the transcript segment element is valid (green check) but summary gives error. This appears to happen when invalid position is passed. I think we might want better error messages. This can be a new issue.

Screen.Recording.2024-08-26.at.07.06.37.mov

@korikuzma
Copy link
Member

@katiestahl do you know why this one is failing?

Screen.Recording.2024-08-26.at.07.14.01.mov

fieldValue={txChrom}
errorText={txChromText}
onChange={handleChromosomeChange}
/>
<Box mt="18px" width="125px">
<StrandSwitch setStrand={setTxStrand} selectedStrand={txStrand} />
Copy link
Member

Choose a reason for hiding this comment

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

Strand can be removed from transcript segment element. Maybe templated sequence too (not sure how this one works)?

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'll remove the ability to change it for tx element. I think it might be fine to leave in the UI as a helpful visual tool to the user, though. what are your thoughts on that?

It looks like we still require the user to put in the strand for Templated Sequence, though. That element is pretty much entirely user-made, whereas tx makes a request to cool-seq-tool. If this is something cool-seq-tool can do now, we should def make a new issue for it!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

pushed a commit where the ability to change it is removed, but it'll still show the strand to the user! I can also just remove it altogether- I just wasn't sure if it was a helpful visual aid or not

Copy link
Member

Choose a reason for hiding this comment

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

@katiestahl so it makes sense for transcript segment element when Genomic coordinates, gene is selected as input data since strand is automatically generated. However, Genomic coordinates, transcript does not change the strand. For example, NC_000011.10 and NM_003390.3 should change strand to positive, but it stays negative

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@korikuzma is it okay if I create a new ticket for that? This is not something that was working or implemented like this before, so I think it's outside of the scope of this ticket. I'll create a new issue though

Copy link
Member

Choose a reason for hiding this comment

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

Can we hide the strand for now so it's not confusing and back back in #321

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yep!

@katiestahl katiestahl merged commit 5ad0ec1 into staging Aug 27, 2024
5 checks passed
@katiestahl katiestahl deleted the cool-seq-tool-tx-updates branch August 27, 2024 18:02
@korikuzma korikuzma mentioned this pull request Sep 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build Changes that affect the build system or dependencies priority:high High priority
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants