Skip to content
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

fix: re-cue unmatched cues in Respondant #797

Merged

Conversation

iFergal
Copy link
Contributor

@iFergal iFergal commented Jun 5, 2024

Should resolve WebOfTrust/keria#184.

In KERIA, the Respondant processes certain cues for a kevery, but it drops other cues like keyStateSaved and Phil has suggested this to be the safest change to make to resolve the issue.

Since we are pushing the cue back onto the Deck, I needed to process one item per tock instead of looping the entire Deck and then yielding. An alternative is to keep another list of items and re-add them all after while self.cues is finished but I find this risky in case there are a lot of items and the process dies half way through.

Copy link
Member

@pfeairheller pfeairheller left a comment

Choose a reason for hiding this comment

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

Looks good to me, exactly what we discussed in Discord.

@pfeairheller pfeairheller merged commit 38cc289 into WebOfTrust:main Jun 5, 2024
6 checks passed
@iFergal iFergal deleted the fix/respondantRecue branch June 5, 2024 14:46
kentbull pushed a commit to kentbull/keripy that referenced this pull request Jul 8, 2024
kentbull pushed a commit to kentbull/keripy that referenced this pull request Sep 3, 2024
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.

client.keyStates().query() does not work without sn
2 participants