-
Notifications
You must be signed in to change notification settings - Fork 0
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
Conversation
This PR is stale because it has been open 1 day(s) with no activity. Please review this PR. |
} | ||
}, | ||
check_coords_response, | ||
) | ||
|
||
await check_response( | ||
"/api/utilities/get_exon?chromosome=1", |
There was a problem hiding this comment.
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( |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at this now
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
tests failing is a preexisting issue: #303 |
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
@jarbesfeld Are you able to review this? |
@korikuzma Yes I can test UI as well |
There was a problem hiding this 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
"exonStartOffset": 5, | ||
"exonStartOffset": 72, | ||
"exonEnd": 6, | ||
"exonEndOffset": -71, | ||
"gene": tpm3_descriptor, | ||
"exonEndOffset": -5, | ||
"gene": tpm3_gene, |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
@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 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. on it! |
…ariants/fusion-curation into cool-seq-tool-tx-updates
…ill revisit at a later date
@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. 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; |
There was a problem hiding this comment.
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?)
There was a problem hiding this comment.
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
There was a problem hiding this 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
@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} /> |
There was a problem hiding this comment.
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)?
There was a problem hiding this comment.
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!
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep!
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