Summary

I refactored the draft auto-save and restore logic to use dedicated utility functions, ensured proper draft encoding/decoding, and fixed a blank page issue when an SSE stream is cancelled before a response is received.

• Moved encodeBase64, decodeBase64, and clearDraft into a new drafts.ts utility file for modularity and reuse
• Updated useAutoSave hook to utilize the new draft utility functions, reducing redundant code and improving reliability
• Implemented setDraft and getDraft helpers; all draft-related logic and storage centralized for clarity
• Fixed getDraft to always decode stored draft values before returning them to avoid showing invalid base64 data in the input field
• Handled a specific edge case in useEventHandlers where stream cancellation before any response would previously result in a blank conversation page, now preventing navigation and properly restoring any previous or empty draft state
• Ensured conversation message state and draft input retain consistency in interrupted or failed conversations

Change Type

• Bug fix (non-breaking change which fixes an issue)
• Refactor (code quality improvement, no behavior change)
• Documentation update (added or improved inline comments)

Testing

I manually tested the following scenarios in the LibreChat UI:

• Draft auto-saving and restoration when navigating between conversations and after refresh
• Cancelling a streaming response before any content arrives: confirmed the page does not go blank and past drafts/messages persist or reset as expected
• Draft text consistently appears decoded in the input field after reloads or navigation
• All storage relevant to draft content is encoded/decoded appropriately

Test Configuration:

• Latest LibreChat main branch
• Chrome browser
• Tested both new and existing conversations with and without SSE response interruptions

Checklist

• My code adheres to this project's style guidelines
• I have performed a self-review of my own code
• I have commented in any complex areas of my code
• I have made pertinent documentation changes
• My changes do not introduce new warnings
• I have written tests demonstrating that my changes are effective or that my feature works (manual verification for edge cases)
• Local unit tests pass with my changes