Skip to content

feat(scheduler): Allow bypassing queue logic via CardAnswer flag #3976

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

Merged
merged 2 commits into from
May 3, 2025

Conversation

xuanyue202
Copy link
Contributor

@xuanyue202 xuanyue202 commented May 2, 2025

Problem

Currently, the backend scheduler assumes all card answers processed via the answer_card endpoint originate from the standard review queue (from_queue is implicitly true). This doesn't accurately represent scenarios like card previews or potentially some custom study sessions where answering a card should not affect the main queue counts or state.

Solution

This PR introduces an optional boolean field from_queue to the CardAnswer protobuf message definition (proto/anki/scheduler.proto).

When from_queue is set to false by the client, the backend service (rslib/src/scheduler/service/answering.rs) will now set the internal from_queue flag to false for that specific answer. This allows the scheduler to correctly handle answers that should not modify the standard queue state.

If from_queue is omitted or set to true, the behavior remains unchanged (the answer is considered from_queue = true).

Impact

This change provides more flexibility for clients interacting with the scheduler, enabling them to distinguish between answers that are part of the normal review flow and those that occur outside of it (e.g., previews), ensuring queue metrics remain accurate.

Copy link
Collaborator

@abdnh abdnh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@abdnh abdnh merged commit 1f95d03 into ankitects:main May 3, 2025
1 check passed
@dae
Copy link
Member

dae commented May 19, 2025

Reverting this due to #3983

If a separate method proves necessary in the future, we should address this issue at the same time.

dae added a commit that referenced this pull request May 19, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants