Create_init_custom_data in case of first rating using the plugin is TOO-EARLY

[hugomarins]

It looks like if the first rating using the plugin of a card with previous review history if TOO-EARLY, no CustomData is stored:

But after 1 hour, when the card is shown, the Init_custom_data will be calculated, and will get an incorrect initial stability (relevant difference if that 'TOO-EARLY' was pressed in a very overdued card). Because the initial stability will be calculated as if [that 'TOO-EARLY' pressing day (-) the previous review date] was the previous interval, when in fact this is not:

(Am I not thinking clearly here?)

I noticed that the calculated stability was strange for a card with this edge case:

The new stability was too long for my settings (and exactly matched the one that would be correct if the last interval was indeed ['TOO-EARLY' pressing day (-) the previous review date ], instead of 3.7 months).

I wouldn't bother you if I knew how to solve this. Can you help me?

[hugomarins]

Another example card (jumped from a 13d stability to 2.6y):

[L-M-Sherlock]

Because the initial stability will be calculated as if [that 'TOO-EARLY' pressing day (-) the previous review date] was the previous interval, when in fact this is not:

fsrs4remnote/src/widgets/index.tsx

Line 92 in 1ff65a5

const revlogs = filterUnusedQueueInteractionScores(history);

The 'TOO-EARLY' review has been filtered out of the revlogs.

[hugomarins]

The problem is that filtering the TOO-EARLY, the information of the Target Date ("scheduled" of the RepetitionStatus) [in the blue circle in the image below] is lost, making it impossible to recover the stability ("Next Interval") information.

The algo is reconstructing the stability based on incorrect dates, as the one needed has been lost when TOO-EARLY was filtered of the revlog history. (in the example above, stability was calculated as if being 1 year, and not 2 months as it should be).

@bjsi , I saw that of all info of the metadata history shown in RemNote (above), "Next Interval" is the only one that in not possible to recover in this structure:

Can't you include this info in the RepetitionStatus interface? If it were there, we would be able to ignore TOO-EARLY review and yet have the needed info to stablish the correct stability in the init_custom_data (first time the FSRS is used in the history of the card).