update our cache key in useAgentChat to include agent name (fix for #420) #531
Conversation
🦋 Changeset detectedLatest commit: 53ed507 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Update the cache key in useAgentChat to include the agent name, addressing issue #420.
commit: |
|
That's odd. Doesn't agentUrlString already include the name and id? |
so here is my theory: when you call useAgent with a new name, it just mutates the same socket. It updates agent.name = newName, but the socket itself is still hanging on to the old _pkurl until it reconnects and PartySocket runs setWSProperties again. During that gap, if you check the URL, you’ll still see the old one (including the old room ID), so it doesn’t line up with the new thread. That stale URL is what the cache picks up, which is why you end up serving the previous conversation. On the other hand, if you unmount and remount, the socket gets rebuilt from scratch, so _pkurl is set with the new room right away, that's why it's not always happening, I think. I re-wrote the tests (initial ones had wrong URLs), tests these one again and I think this is the fix That's my main theory, correct me if I'm wrong |
|
switching this to draft for now, gonna go dig into partysocket to see what's happening in there |
this fixes #420
so previously when we switch from threadId-1 to threadId-2, we would use agentUrlString as the cache key, which in this cause would be identical for both agents and the cache would return the msgs for thread1, instead of thread2
wrote tests for the initial bug, failed as expected, added agent.name to the cacheKey and now all is passing