#Can we query the workflows table from Workflow component to see active tasks?

9 messages · Page 1 of 1 (latest)

steady horizon
#

Any guidance on filtering this per-user or etc? Or should I track this information myself?

thick zinc
#

I would track the info yourself - put the workflowId in a table associated with your user / message / usecase, then use that to query the status

hasty pebble
#

is there no way currently to query the component tables directly?

thick zinc
#

No you can't query the data directly - the API boundary is intentional, but ideally the right information is available - what data are you trying to access? I'm open to both PRs and suggestions for API improvements

hasty pebble
# thick zinc No you can't query the data directly - the API boundary is intentional, but idea...

Gotcha. I was trying to implement pagination with search for the threads table, but I wasn’t able to get it working. I ended up creating a new table called “threadMetadata” and storing the titles in there as well. There was some other data I wanted to store about threads, so I would have had to do this at some point anyway, but now I have two tables containing the thread title.

I could definitely see why you wouldn’t want people adding or removing columns to the component tables, as that could cause issues if your team decides to introduce a new column that conflicts with one a user added. What is the reasoning behind the API boundary for queries though? Having the prebuilt functions is nice, but what’s the harm in letting us query the data directly?

thick zinc
#

Fair question, as reads are generally safer. A big one is hiding internal state - in bigger applications it can get really messy when separate parts of the application depend on state that was meant to be internal. Making changes to that state becomes hard to reason about - because you don't know who depended on what assumptions about which fields. For instance I've been able to drop the old "steps" table without worrying because I never had exposed that table directly, and I am able to add/modify fields internally so long as I conform to the old API. Especially for components like workpool, workflow, etc. there's a lot of internal "bookkeeping" that would be misleading to query from the outside and may change over time.
So for components we're holding a firmer line with having the API boundary be the contract between the application & component.

hasty pebble
# thick zinc Fair question, as reads are generally safer. A big one is hiding internal state ...

Gotcha ok, that makes a lot of sense. I'll keep going about it the way I have been, making new tables whenever I need to store more info.

One thing that might be a nice addition to the agent component would be an updatedAt field for the threads table. When I list a user's threads in the side of my app, I want old threads to shoot to the top if they send a new message in them. Looking around, that seems to be the standard in AI chat apps. I was able to achieve that by manually adding an updatedAt field to my new table, but it would be nice to have that built in!

thick zinc
#

Great idea - filed! https://github.com/get-convex/agent/issues/66
I think it'd be cool to return the full latest message per thread - since often you want to hint at what that message is.
Something you can do today if you want this:
When returning the threads, look up the latest message and return that in the list too. Then client-side you can sort by most recent thread or most recent message. Though that assumes you can paginate enough recent threads to include the most recent messages.
But adding a includeAndSortByLatestMessage seems like it'd solve both use-cases and allow paginating by recency.

GitHub
Add updatedAt to thread listing · Issue #66 · get-convex/agent

Allow listing threads by the latest message time Internally can denormalize, or use a Distinct on messages sorted by time Possibly the query instead is includeLatestMessage that gives back the thre...