Bug Fix #1938 #2019
Open
Bug Fix #1938 #2019
Conversation
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
jubalh
requested changes
Feb 10, 2025
There was a problem hiding this comment.
Thanks for this PR.
Before I look at the code itself. Please make sure you follow.
So first thing you have to do is find the contributing.md file. Read it.
Then you can check other PRs and see what they look like.
You describe the PR as comments in the code. You will find out that nobody else is doing this :) Use the body of the git commit message.
Once you are done you can click on request review.
|
Ping |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
For the bug reported in #1938 there seems to be an issue of not grabbing the right time stamp. This is similar to the bug in #1190 of not grabbing the proper delay for MAM messages. To fix this, instead of discarding the original timestamp and trying to find the oldest delay, which may have been lost to a server quirk, we preserve the timestamp until an older delay is found. Then, and only then, will the timestamp update. Of course if it still can't find a delay and there is no timestamp, the fall back of grabbing the current time is still available. This should fix the bug experienced in #1938 and #1190 , given they look like they stem from a similar issue.
How to test the functionality
*Step 3 - Connect Profanity
Now the timestamps should be correct for the MUC.
Previous to this there were issues of inaccurate time stamps, but now that should be mitigated.