waves: warn that a wave too short to earn points will not count - #3486
Conversation
A wave is a comment on the chain, so the points backend applies the same minimum length to it as to a reply: at or under the threshold once URLs are stripped, it earns nothing and never reaches the daily comment quest. #3473 closed this for the reply composer and left waves out of scope. Measuring it since: about one in six waves posted from Ecency falls under the threshold. Waves are short by design, which is exactly why the rule bites here. The indexer and the points backend agree on the same set over the same window, so that is a count rather than an estimate. The helper generalises rather than being written a second time: it no longer gates on reply-versus-wave, since every caller composes a comment. The post editor keeps that gate at its own call site, where a body short enough to trip the rule is not a real case and would only be noise. Renamed to match what it now covers, and to match the web helper of the same name. No mode gate in the quick post composer: both live modes submit a comment, and it only ever creates, so there is no editing case to exclude. It already re-renders per keystroke for the character counter, so the hint sits at the other end of that same range and costs nothing extra. The hint never blocks submitting. What gates the button is unchanged: the pre-existing upper character limit on waves. Closes #3485
|
Warning Review limit reached
Next review available in: 37 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (8)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9fad2456d2
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| shouldShowShortContentHint({ | ||
| username: currentAccount?.name, | ||
| body: commentValue, | ||
| }), |
There was a problem hiding this comment.
Measure the body that will actually be submitted
When a wave contains only an attached image or video, commentValue is empty, so shouldShowShortContentHint treats the composer as untouched and suppresses the warning. However, _submitPost later appends videoEmbedUrl or the image Markdown before publishing; once that URL is excluded, this submitted body is still below the reward threshold. Pass the composed body—or account for the attachment state—so media-only waves receive the warning this change is intended to provide.
Useful? React with 👍 / 👎.
Closes #3485. Mirrors ecency/vision-web#1400.
A wave is a comment on the chain, so the points backend applies the same minimum length to it as to a reply: at or under the threshold once URLs are stripped, it earns nothing and never reaches the daily comment quest. #3473 closed this for the reply composer and left waves out of scope.
About one in six waves posted from Ecency falls under the threshold. Waves are short by design, which is exactly why the rule bites here. The indexer and the points backend agree on the same set over the same window, so that is a count rather than an estimate.
It does not block submitting
Worth stating plainly, since the composer already blocks on length at the other end of the range. The hint is display-only:
showShortContentHintappears exactly twice in the file, at its definition and in the render, and in nodisabledprop or submit guard. What gates the button is unchanged, the pre-existingbodyLengthExceededupper limit on waves. Short content still posts, it just does not pay, and now the user can see that before sending rather than an hour later on Perks.Same holds for the reply composer this PR also touches, and for both web composers.
Generalising rather than duplicating
The helper no longer gates on reply-versus-wave, because every caller composes a comment. The post editor keeps that gate at its own call site, where a body short enough to trip the rule is not a real case and would only be noise. Renamed to
shouldShowShortContentHint/shortContentHint.tsto match what it now covers, and to match the web helper of the same name. Moved withgit mvso the history follows.No mode gate in the quick post composer: both live modes (
commentandwave) submit a comment, and it only ever creates, so there is no editing case to exclude. It already re-renders per keystroke for the character counter, so the hint costs nothing extra there. That is unlike the post/reply editor, which is uncontrolled on purpose and still measures on its debounce.Verification
Run against the real published
@ecency/sdk2.3.79 rather than the older copy in the shared install.The helper's tests carry over and gain a wave case. The reply editor's behaviour is unchanged, which the untouched existing cases confirm.
Not covered by tests: the rendering in either composer, which needs them stood up. Worth a look that the hint reads sensibly under the wave input and does not fight the character counter.