checking and fixing broken PsiStore when using PsiStore importer
Nobody has claimed this yet.
- Dominant language
- C#
- Stars
- 574
- Forks
- 104
- Avg merge
- 19m
- Merged PRs (30d)
- 1
Description
There currently isn't any indication for when I open a broken PsiStore in code. For example, if the store that I open below is broken, the code will just execute with no indication of error.
var store = PsiStore.Create(p, "BodyMergerTest", @"C:\Data\Store\BodyMergerTest");
var input = PsiStore.Open(p, "record-pipeline", @"C:\Data\Store\Recording\record-pipeline.0013");
var bodies1 = input.OpenStream<List<AzureKinectBody>>("azure1.bodies");
bodies1.Write("bodies1", store);
p.Run();
However, when you open the newly saved PsiStore in PsiStudio, the message will now have message creation time of when the code is executed instead of an offset to the PsiStore's originating time. There are also other problems such as other components' message not passing, etc. I traced the problem back to the broken PsiStore have broken streammetas which didn't update the Pipeline's replay time correctly.
The workaround right now is to fix the PsiStore with PsiStudio first then loading it. Since PsiStudio can recognize the problem, I think having PsiStore.Open do the same thing or convey to the programmer there is a problem will be helpful.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at PsiStore.Open and compare its handling with PsiStudio's recognition of broken streammetas. Trace how broken metadata affects the Pipeline replay time and message propagation. Done means opening a broken store no longer fails silently and clearly reports the problem or prevents incorrect replay behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- stream-processing
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100