Bug Report - Missing `from` Attribute in `thread.create_reply` Function
Closed this issue · 3 comments
Description
Problem Statement
While working on the development of this Code Inbox endpoint, I encountered a bug related to the create_reply
function in the Nylas SDK. This function, when used to create a reply to an email, returns a draft that is missing the from
or from_
attribute.
This issue is causing problems as it prevents users from accessing the sender's information, which is crucial for various purposes. I was able to come up with a workaround that involves removing the user sending the reply from the participant's list to avoid exceptions, but this is not an ideal solution.
Steps to Reproduce
- Use the
create_reply
function in the Nylas SDK to create a reply to an email. - Attempt to access the
from
attribute in the resulting draft.
Current Behavior
The from
or from_
attribute is missing in the draft returned by the create_reply
function. This results in a key error or attribute missing exception when trying to access the sender's information.
Expected Behavior
I would expect the create_reply
function to return a draft with the same functionality as the nylas.drafts
module, which includes the from
attribute. This behavior is consistent with the user's expectations and makes it easier to work with the created drafts.
Workaround
As mentioned earlier, I came up with a workaround that involves removing the user sending the reply from the participant's list to avoid exceptions. However, this workaround is not a long-term solution and does not provide access to the sender's information.
Suggested Solution
To resolve this issue, I recommend implementing the same functionality in the create_reply
function as is found in nylas.drafts
, which includes the from
attribute. This would ensure that the drafts created using create_reply
include the necessary sender information.
Impact
The current bug affects the functionality and usability of the Nylas SDK, specifically in the context of creating email replies. A fix for this issue would improve the overall developer experience and ensure that the create_reply
function provides the expected and consistent behavior.
Additional Information
Thank you for addressing this bug report. Please let me know if you require any further information or clarification. This bug is currently a significant obstacle, and I believe that resolving it will greatly enhance the usability of the Nylas SDK.
Thanks for opening the issue @wiseaidev. I have tried to reproduce the issue you are encountering but I am not seeing it on my side. Here's the code I used:
from nylas.client import APIClient
nylas = APIClient(
"snip",
"snip",
"snip",
)
thread = nylas.threads.first()
draft = thread.create_reply()
print(draft)
draft.from_ = [{"name": "From", "email": "test@gmail.com"}]
print(draft)
and the output is:
{'id': None, 'cls': <class 'nylas.client.restful_models.Draft'>, 'api': <nylas.client.client.APIClient object at 0x104bcd910>, 'file_ids': [], 'thread_id': 'byrnthnyk385wp9zxhflmcmqz', 'subject': 'Hello World'}
{'id': None, 'cls': <class 'nylas.client.restful_models.Draft'>, 'api': <nylas.client.client.APIClient object at 0x104bcd910>, 'file_ids': [], 'thread_id': 'byrnthnyk385wp9zxhflmcmqz', 'subject': 'Hello World', 'from_': [{'name': 'From', 'email': 'test@gmail.com'}]}
The underlying function is simple, and it uses nylas.drafts.create()
so it should be creating a Draft object. I saw your code snippet and it looks fine. What version of Python are you using?
Hey @mrashed-dev, try to call draft.send
after setting draft.from_
. Last time I used it, it threw an error.
@wiseaidev I have tried again with draft.send
after setting draft.from_
and it does indeed work with the v5 SDK:
from nylas.client import APIClient
nylas = APIClient(
"snip",
"snip",
"snip",
)
thread = nylas.threads.first()
draft = thread.create_reply()
draft.from_ = [{"name": "From", "email": "test@gmail.com"}]
draft.to = [{"name": "To", "email": "destination@gmail.com"}]
sent = draft.send()
print(sent)
I'm closing this issue for now, feel free to reopen it if you're still running into this issue!