Repository navigation
docs(chat): correct the fallback-window comment, which claimed a match that did not exist - #797
Merged
Merged
Conversation
…h that did not exist `MessagePolicy.fallbackEditWindow`'s doc said the value matches Android's, so the two clients offer the same rows for the same message. Android had no such constant: it treated an unset `message_edit_window` as no limit and kept Edit and Delete available forever. The claim arrived with the constants in #724, whose commit message repeated it. Android now carries `FallbackEditWindow` / `FallbackDeleteWindow` with these two values, so the parity the comment asserted holds — but as a duty nothing enforces, not a fact. The doc says that instead, names the Kotlin counterpart, and records that the match had to be created rather than found. Behaviour is unchanged; this is comments and the design spec. That spec said the edit window defaults to none and would become a constant only if the backend documented a window, which is the reading Android had implemented. It is superseded in place, naming both clients' constants.
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
1 participant
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.
MessagePolicy.fallbackEditWindow's doc said the value matches Android's, so the two clients offer the same rows for the same message. Android had no such constant. It treated an unsetmessage_edit_windowas no limit and kept Edit and Delete available forever, which is the opposite behaviour. The claim arrived with the constants in #724, whose commit message repeated it, so the error was in the change that introduced them rather than in the comment alone.Android now carries
FallbackEditWindow/FallbackDeleteWindowwith these two values, so the parity the comment asserted holds — but as a duty nothing enforces, not a fact. The doc says that instead, names the Kotlin counterpart, and records that the match had to be created rather than found. The parity test gains a comment saying a failure here is the prompt to change Android in the same release.Behaviour is unchanged. This is comments, a test comment, and the design spec.
The spec said the opposite
docs/superpowers/specs/2026-09-01-chat-message-actions-design.mdsaid the edit window defaults to none and would become a constant only if the backend documented a window — which is the reading Android had implemented. It is superseded in place, naming both clients' constants and recording that the backend still documents nothing.That leaves the values as a product guess on both platforms. The proto documents what
message_edit_windowandmessage_delete_windowmean but never what an absent one implies. Whether real users ever reach the fallback is unknown: the cached-flag reads that could have answered it were all staff accounts.The Android side is code-payments/code-android-app#1486, which adds the two constants and switches the default policy to them.