Switch replies to rich text#513
Open
rob93c wants to merge 7 commits into
Open
Conversation
rob93c
added
enhancement
Contributor
📝 WalkthroughWalkthroughThe bot's text-response mechanism is migrated from ChangesRich-message migration and /supported command
Sequence Diagram(s)sequenceDiagram
participant Client as Telegram Client
participant Stickerify as Stickerify Bot
participant TelegramAPI as Telegram API
rect rgba(173, 216, 230, 0.5)
Note over Client, TelegramAPI: Text command (e.g. /start, /help, /supported)
Client->>Stickerify: Command message
Stickerify->>TelegramAPI: sendRichMessage(InputRichMessage.markdown(answer.getText()))
end
rect rgba(144, 238, 144, 0.5)
Note over Client, TelegramAPI: File processing
Client->>Stickerify: File upload
Stickerify->>TelegramAPI: sendRichMessageDraft(PROCESSING_MESSAGE)
Stickerify->>TelegramAPI: sendDocument(converted file)
Stickerify->>TelegramAPI: sendRichMessage(InputRichMessage.markdown(FILE_READY.getText()))
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/main/java/com/github/stickerifier/stickerify/telegram/model/TelegramRequest.java (1)
83-88:⚠️ Potential issue | 🟠 MajorNormalise bot commands by stripping the optional
@usernamesuffix before switching onmessage.text().Telegram bot commands in group chats are sent with the bot's username appended (e.g.
/start@MyBot_bot). The current implementation uses exact string matching, which will fail to recognise these commands and fall through to the default case, returningABOUTinstead of the correct answer. This affects bothgetAnswerMessage()andisNewUser(). Extract the command portion before the@symbol or use a helper method to normalise the text before the switch.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/main/java/com/github/stickerifier/stickerify/telegram/model/TelegramRequest.java` around lines 83 - 88, The switch statement in the getAnswerMessage() method (and similarly in isNewUser()) operates directly on message.text() without normalizing bot commands. Telegram bot commands in group chats include the optional `@username` suffix (e.g., /start@MyBot_bot), so exact string matching will fail to recognize these commands and fall through to the default case. Create a helper method that extracts the command portion before the @ symbol (or returns the full text if no @ is present), then use this normalized text in the switch statement in both getAnswerMessage() and isNewUser() methods.
🧹 Nitpick comments (1)
src/main/java/com/github/stickerifier/stickerify/telegram/Answer.java (1)
47-69: ⚡ Quick winKeep the rich-text format in the enum contract.
PROCESSINGis HTML, while the other answers are markdown, butAnswernow only exposes raw text. Downstream code already has to special-caseAnswer.PROCESSINGinsrc/test/java/com/github/stickerifier/stickerify/bot/StickerifyTest.javaLines 64-66, so the contract is now split across files. Please add aRichMessageFormat/MessageFormatfield to the enum and let callers read it instead of branching on specific enum values.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/main/java/com/github/stickerifier/stickerify/telegram/Answer.java` around lines 47 - 69, The Answer enum currently mixes HTML and markdown formats without exposing this information, forcing downstream code to special-case the PROCESSING enum value. Add a RichMessageFormat (or MessageFormat) field to the Answer enum to track whether each answer is HTML or markdown. Update each enum constant (PROCESSING, SUPPORTED_FORMATS, and any others) to specify their respective format, modify the Answer constructor to accept this format parameter, and add a getter method (like getFormat()) to expose it. This allows callers to check the format via the enum field instead of branching on specific enum values.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/main/java/com/github/stickerifier/stickerify/bot/Stickerify.java`:
- Around line 151-152: The order of operations in the file upload workflow is
incorrect. Currently, the FILE_READY message is sent via answerText before the
actual document upload via execute(answerWithFile), which means users could
receive a success notification even if the file upload fails. Reverse the order
of these two calls: execute the document send operation first using
answerWithFile, and then send the FILE_READY message via answerText only after
the upload completes successfully.
In `@src/main/java/com/github/stickerifier/stickerify/telegram/Answer.java`:
- Around line 50-59: The SUPPORTED_FORMATS constant now advertises support for
animated stickers alongside static and video stickers, but the HELP and ERROR
response constants still only reference standard and video sticker support.
Update both the HELP and ERROR message constants in the Answer class to include
animated stickers in their descriptions of supported sticker types, ensuring all
user-facing messages provide consistent guidance about the three supported
sticker formats.
---
Outside diff comments:
In
`@src/main/java/com/github/stickerifier/stickerify/telegram/model/TelegramRequest.java`:
- Around line 83-88: The switch statement in the getAnswerMessage() method (and
similarly in isNewUser()) operates directly on message.text() without
normalizing bot commands. Telegram bot commands in group chats include the
optional `@username` suffix (e.g., /start@MyBot_bot), so exact string matching
will fail to recognize these commands and fall through to the default case.
Create a helper method that extracts the command portion before the @ symbol (or
returns the full text if no @ is present), then use this normalized text in the
switch statement in both getAnswerMessage() and isNewUser() methods.
---
Nitpick comments:
In `@src/main/java/com/github/stickerifier/stickerify/telegram/Answer.java`:
- Around line 47-69: The Answer enum currently mixes HTML and markdown formats
without exposing this information, forcing downstream code to special-case the
PROCESSING enum value. Add a RichMessageFormat (or MessageFormat) field to the
Answer enum to track whether each answer is HTML or markdown. Update each enum
constant (PROCESSING, SUPPORTED_FORMATS, and any others) to specify their
respective format, modify the Answer constructor to accept this format
parameter, and add a getter method (like getFormat()) to expose it. This allows
callers to check the format via the enum field instead of branching on specific
enum values.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 5dcbf90b-4066-47e4-b60c-262f0f8fb91e
📒 Files selected for processing (6)
build.gradlesrc/main/java/com/github/stickerifier/stickerify/bot/Stickerify.javasrc/main/java/com/github/stickerifier/stickerify/telegram/Answer.javasrc/main/java/com/github/stickerifier/stickerify/telegram/model/TelegramRequest.javasrc/test/java/com/github/stickerifier/stickerify/bot/MockResponses.javasrc/test/java/com/github/stickerifier/stickerify/bot/StickerifyTest.java
Comment on lines
+151
to
152
| answerText(FILE_READY, request); | ||
| execute(answerWithFile); |
Contributor
There was a problem hiding this comment.
Send the document before announcing it is ready.
At Line 151, FILE_READY is sent before the upload at Line 152. If sendDocument fails, users can receive a success message without a file (and then an error path). Execute the document send first, then send the ready text only on success.
Suggested fix
- answerText(FILE_READY, request);
- execute(answerWithFile);
+ execute(answerWithFile);
+ answerText(FILE_READY, request);🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/main/java/com/github/stickerifier/stickerify/bot/Stickerify.java` around
lines 151 - 152, The order of operations in the file upload workflow is
incorrect. Currently, the FILE_READY message is sent via answerText before the
actual document upload via execute(answerWithFile), which means users could
receive a success notification even if the file upload fails. Reverse the order
of these two calls: execute the document send operation first using
answerWithFile, and then send the FILE_READY message via answerText only after
the upload completes successfully.
Comment on lines
+50
to
+59
| SUPPORTED_FORMATS(""" | ||
| | Type | Supported formats | | ||
| |:---------|:------------------------------------------------| | ||
| | images | png, jpg, static webp, tiff, ico, svg, psd | | ||
| | videos | gif, mov, avi, mp4, webm, m4v, mkv, live photos | | ||
| | stickers | static, video, animated | | ||
|
|
||
| If you have any questions or concerns, feel free to reach out to us\\. | ||
| --- | ||
|
|
||
| If you want to see a format added, please let us know by creating an issue on [GitHub](https://github.com/Stickerifier/Stickerify/issues/new). |
Contributor
There was a problem hiding this comment.
Keep the support copy consistent across replies.
SUPPORTED_FORMATS now advertises animated stickers, but HELP and ERROR still describe sticker support as only standard/video. Users will get different guidance depending on which reply they hit.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/main/java/com/github/stickerifier/stickerify/telegram/Answer.java` around
lines 50 - 59, The SUPPORTED_FORMATS constant now advertises support for
animated stickers alongside static and video stickers, but the HELP and ERROR
response constants still only reference standard and video sticker support.
Update both the HELP and ERROR message constants in the Answer class to include
animated stickers in their descriptions of supported sticker types, ensuring all
user-facing messages provide consistent guidance about the three supported
sticker formats.
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.
Summary by CodeRabbit
Release Notes
New Features
/supportedcommand to display all supported file formats in a table.Tests