Skip to content

Conversation

@iceljc
Copy link
Collaborator

@iceljc iceljc commented Oct 15, 2025

PR Type

Bug fix


Description

  • Fixed message deletion response handling in chat resend functionality

  • Updated return type annotation from string to any for message deletion

  • Changed variable access from resMessageId to res?.messageId for proper object destructuring


Diagram Walkthrough

flowchart LR
  A["User resends message"] --> B["deleteConversationMessage called"]
  B --> C["Returns response object"]
  C --> D["Extract messageId from response"]
  D --> E["sendChatMessage with messageId"]
Loading

File Walkthrough

Relevant files
Bug fix
chat-box.svelte
Fix message ID extraction from deletion response                 

src/routes/chat/[agentId]/[conversationId]/chat-box.svelte

  • Updated promise resolution to use response object instead of direct
    message ID
  • Changed variable from resMessageId to res with property access
    res?.messageId
+2/-2     
conversation-service.js
Update return type annotation for message deletion             

src/lib/services/conversation-service.js

  • Updated JSDoc return type from Promise to Promise
  • Reflects actual response structure being an object rather than string
+1/-1     

@iceljc iceljc merged commit f9dccd9 into SciSharp:main Oct 15, 2025
1 check failed
@qodo-merge-pro
Copy link

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
Unhandled promise case

Description: Potential unhandled rejection or undefined property access when using
deleteConversationMessage().then(res => sendChatMessage(... res?.messageId)) without
catch/fallback may cause runtime issues if the promise rejects or response lacks
messageId.
chat-box.svelte [1115-1119]

Referred Code
if (result.value) {
	const postback = buildPostback(message?.message_id);
	deleteConversationMessage(params.conversationId, message?.message_id, true).then(res => {
		sendChatMessage(message?.text, { postback: postback, inputMessageId: res?.messageId });
	});
Ticket Compliance
🎫 No ticket provided
- [ ] Create ticket/issue <!-- /create_ticket --create_ticket=true -->

</details></td></tr>
Codebase Duplication Compliance
Codebase context is not defined

Follow the guide to enable codebase context checks.

Custom Compliance
No custom compliance provided

Follow the guide to enable custom compliance check.

Compliance status legend 🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

@qodo-merge-pro
Copy link

PR Code Suggestions ✨

Explore these optional code suggestions:

CategorySuggestion                                                                                                                                    Impact
Possible issue
Add check for message ID

Add a check to ensure res?.messageId exists before calling sendChatMessage, and
handle the case where it is missing to prevent silent failures.

src/routes/chat/[agentId]/[conversationId]/chat-box.svelte [1117-1119]

 deleteConversationMessage(params.conversationId, message?.message_id, true).then(res => {
-	sendChatMessage(message?.text, { postback: postback, inputMessageId: res?.messageId });
+	if (res?.messageId) {
+		sendChatMessage(message?.text, { postback: postback, inputMessageId: res.messageId });
+	} else {
+		console.error('Could not retrieve messageId after deletion.');
+		// Optionally, inform the user that the follow-up action failed.
+	}
 });
  • Apply / Chat
Suggestion importance[1-10]: 7

__

Why: This suggestion correctly points out a potential silent failure where sendChatMessage could be called with an undefined inputMessageId. Adding an explicit check for res?.messageId makes the code more robust and prevents potential bugs.

Medium
General
Use a specific object type

In the JSDoc for deleteConversationMessage, replace the generic Promise return
type with the more specific Promise<{messageId: string}>.

src/lib/services/conversation-service.js [188]

-* @returns {Promise<any>}
+* @returns {Promise<{messageId: string}>}
  • Apply / Chat
Suggestion importance[1-10]: 5

__

Why: The suggestion correctly identifies that the PR weakens the type definition by using Promise<any> and proposes a more specific type, Promise<{messageId: string}>, based on its usage elsewhere in the PR, which improves code clarity and maintainability.

Low
  • More

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant