[Bug]: FSRS: Buried Sibling Cards Not Surfacing as "New" After Bury Clears + Corrupted Difficulty Values

[tarakanbg]

Describe the bug

Summary

Two related bugs occur when using FSRS with the "Bury sibling cards until the next day" setting enabled on two-way (:::) cards:

1. Buried sibling cards (from NEW cards) do not appear in the review queue the next day (or at least not as NEW), even though the bury list has correctly cleared, hence they probably get assigned some scheduling info and a revision count during the "bury" process.
2. Some reviewed siblings are assigned a wildly out-of-range difficulty value (way above 10) on cards that were created and reviewed entirely under FSRS — not migrated from the previous algorithm.

---

Environment

• Plugin: obsidian-spaced-repetition
• Plugin version: latest (v1.15.1)
• Algorithm: FSRS (freshly switched from SM-2)
• Setting: "Bury sibling cards until the next day" — enabled
• Card type: Two-way / reversed (:::)
• OS: MacOS latest

---

Bug 1: Buried Sibling Does Not Surface After Bury Clears

Observed behaviour

The buried reverse card has valid FSRS scheduling data written into the note comment, with a due date of the previous day and interval of 0. The bury list clears correctly overnight. Despite this, the card does not appear in the review queue as NEW.

Relevant scheduling comment (reverse/buried sibling block)

!fsrs,2026-05-31T13:48:30.331Z,0,2.3065,2.11810397,1,1,0,1,2026-05-31T13:38:30.331Z

Decoded:

Field	Value	Notes
Due	2026-05-31T13:48Z	Previous day — overdue
Interval	0	Same-day scheduling
Difficulty	2.3065	Normal range
Stability	2.118	~2 days
State	1	Learning
Reps	1	Reviewed once
Lapses	0	—
Last review	2026-05-31T13:38Z	Previous day

Hypothesis

The queue builder may not be correctly re-ingesting cards that are in Learning state with interval=0 after they have been through a bury cycle. The bury mechanism writes a valid due date for the sibling at review time, but the queue construction logic on the following day appears to drop these cards.

---

Bug 2: Corrupted Difficulty Value on Reviewed Sibling

Observed behaviour

The forward card (the one actually reviewed, not buried) consistently receives a difficulty value above 10, and sometimes an exact same value (i.e. 18.76074875 was assigned to at least 3 cards) — far outside FSRS's valid difficulty range of 1–10. This has been observed identically across multiple cards, all created and reviewed entirely under FSRS with no prior SM-2 history.

Relevant scheduling comment (full two-sibling comment)

<!--SR:!fsrs,2026-06-20T06:13:53.252Z,19,18.76074875,6.99791867,2,2,0,0,2026-06-01T06:13:53.252Z!fsrs,2026-05-31T13:47:14.565Z,0,2.3065,2.11810397,1,1,0,1,2026-05-31T13:37:14.565Z-->

Forward card decoded:

Field	Value	Notes
Due	2026-06-20	19 days out
Interval	19	days
Difficulty	18.76074875	⚠️ Outside valid range (1–10)
Stability	6.998	~7 days
State	2	Review (graduated)
Reps	2	—
Lapses	0	—
Last review	2026-06-01	Today

Key observations

• The same value (18.76074875) appears across multiple distinct cards, suggesting it is a deterministic output of a specific code path rather than random corruption.
• The reverse sibling of the same card has a normal difficulty value (2.3065), despite being generated in the same session.
• The cards were created and reviewed entirely under FSRS — this is not a migration artefact from SM-2.
• The only structural difference between the two siblings at review time is that the forward card was reviewed while the reverse was being buried simultaneously.

Hypothesis

The difficulty corruption is triggered specifically by the bury interaction during the first review of a two-way card. When FSRS writes the forward card's scheduling data while simultaneously burying the sibling, an incorrect value is passed into the difficulty calculation — possibly an unscaled intermediate, an index, or a value from the wrong field. The bury event appears to corrupt the difficulty of the card that was reviewed, not the one that was skipped.

To Reproduce

1. Enable FSRS and enable "Bury sibling cards until the next day" in settings.
2. Create a new two-way card using ::: syntax (brand new, never reviewed under any algorithm).
3. Review the deck. The forward card is shown; the reverse card is buried.
4. Rate the forward card (e.g. Good or Easy).
5. The bury list correctly records the reverse sibling.
6. The next day: open Obsidian. Confirm the bury list has cleared.
7. Expected: The reverse sibling appears as due today as NEW (Learning state, interval 0, overdue).
8. Actual: The reverse sibling does not appear in the review queue as NEW (although it probably appears as already reviewed and dew, couldn't verify this due to my very long review queue) The overall card count in the deck is correct.

Expected behavior

Expected Behaviour

1. Buried sibling cards with a past due date and Learning state should appear in the review queue the day after the bury clears. Buried NEW never reviewed siblings should appear then next day as NEW and not be assigned scheduling info and a revision count.
2. FSRS difficulty values should always be initialized and updated within the valid range (approximately 1–10). Values such as 18.76074875 should never be produced for a card reviewed for the first time under FSRS.

Screenshots

No response

OS of your device

Mac OS

Obsidian version

1.12.7

Plugin version

1.15.1

Installer version

1.12.4

Additional context

Additional Example Comments

Card with asymmetric migration (forward on FSRS, reverse still on SM-2):

<!--SR:!fsrs,2026-07-01T06:09:52.035Z,30,30.46452326,9.53567837,2,5,0,0,2026-06-01T06:09:52.035Z!2027-03-04,364,256-->

The reverse sibling here was never migrated to FSRS and carries an SM-2 due date of 2027-03-04 (364-day interval). Note the forward card also has an out-of-range difficulty (30.46). This particular card was migrated from SM-2 and reviewed once (one of the siblings) under FSRS.

Config file

No response

[KyleKlus]

Hi, thank you for reporting this 😊. I'll have a look at it😇

[KyleKlus]

Or @kiankyars would you maybe have a look at this, as you implemented the FSRS algorithm and probably are more familiar with its code😇?

[kiankyars]

yes of course, thanks for flagging it @KyleKlus

[KyleKlus]

Thank you 😇.

There is also a bug with a reversable card, where the back is shown first (because of the random card order option) and then the handlePendingRequeue function wants to delete a current card, which isnt there so it produces an error, that the card is undefined 🤔