Repository navigation
fix(application): set aside an answer the log can never add - #667
Merged
Merged
Conversation
The answer log moved past the head of an instance's queue only when the write check refused it. An answer refused for another reason before it was sent, such as a term longer than any read takes in, stayed at the head for good: every later answer of the instance waited behind it, was never logged and was lost when the page closed, while the review states were still saved. Such an answer could come from a course: a wrong option is named in the deck's cards document by the release's distractor id, and an id that fits under the release's short address can be too long under the deck's. Keeping a guest's study re-roots the same option at the instance's address, both on the card and in the answer, so the whole keep failed every time. A card's own id, from a release too, can fit under the guest's short address and not under the instance's, with the same result. The queue now sets aside every refusal made before sending (dataNotConforming, unwritableTerm, termTooLong), and an answer the pod refuses as a bad request (400, 413, 414, 422) a third time. It keeps retrying any other failure, such as no answer, a failed login or a server error, which says nothing of the answer itself. A course answer, and an answer kept from a guest's study, name the wrong option only when its IRI there can be written, and are logged without it otherwise. A card kept from a guest's study is added without such an option, the rest of the card as it was. A card whose own IRI, or the longest name of its review states, would be too long in the new deck is left out with its review states and its answers, so the rest of the study is kept. Refs: GHSA-9fv5-c6xw-wqx5
ixuz
added
bug
ixuz
enabled auto-merge
November 8, 2026 17:07
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What and why
The answer log moved past the head of an instance's queue only when the
write check refused it. An answer refused for another reason before it
was sent stayed at the head for good, so every later answer of the
instance waited behind it and was lost when the page closed, while
review states were still saved. A course's wrong option, or a card id
from a release, that fits under one address but is too long under
another could cause this, and when a guest kept their study it made
the whole keep fail every time.
(dataNotConforming, unwritableTerm, termTooLong), and an answer the
pod refuses as a bad request (400, 413, 414, 422) a third time. It
keeps retrying failures that say nothing of the answer itself: no
answer, a failed login, a server error.
wrong option only when its IRI can be written there, and are logged
without it otherwise.
whose own IRI, or the longest name of its review states, would be too
long in the new deck is left out with its review states and answers,
so the rest of the study is kept. "As a new instance" still fails
safely for such a card (the copy is deleted, the study untouched), as
docs/guest-mode.md says.
docs/data-model.md and docs/guest-mode.md describe the rules.
Refs: GHSA-9fv5-c6xw-wqx5