WIP: Pawel/eng 651 threads management

[PawelMorawian]

No description provided.

[linear]

ENG-651 Update the Thread management in the sdk

Right now the client.thread decorator is only saving a thread_id in the context.

We need to:

• create a proper thread object when using the decorator
• allow devs to send custom tags/metadata/… to the thread through the decorator
• properly queue the thread upsert into the event processor
• add a way to get the thread object client.get_current_thread instead of the current client.get_current_thread_id
• option: document a way to update the thread after having done client.get_current_thread
  • we might simply want to use client.api.update_thread
  • another option is that we decide to send a thread update at the end of the thread with block/decorated function

[willydouhard]

I am not a fan of the needs_upsert concept. Plus this check is always false because it is going to do a reference comparison right?

[PawelMorawian]

"is" keyword is for reference comparison.

>>> k = {}
>>> k == {}
True
>>> k is {}
False
>>> k = {"foo": "bar"}
>>> k == {}
False

[PawelMorawian]

I started by doing a hash comparision and only update on exit when the hash is different but decided against it because this solution seems simpler.

Do you have any preferences on how to do this ?

[willydouhard]

why do we keep the steps in the thread class?

[PawelMorawian]

I guess it is to programatically browser the thread's steps
I have no strong opinion about this

[willydouhard]

i think user should trigger an uspert

[willydouhard]

same here, why we do not account for user?

[willydouhard]

Can you provide an example of what is now possible ? Should we also add this example in the docs?