Khaled K

Alright, thanks 👍

Hey Raphaël Gardies Im working on a similar solution to analyze our intercom tickets. Ive been cleaning the data upstream to keep strictly the message exchanges, the creation date and contacts. At the end, months of Tickets will weight less than 1mo But Im hitting another limit, which is the number of tokens. The short term solution is performing analysis on the data with limited time-frames (i.e, up to the month). The mid-long term solution I'm exploring is to add a step in the cleaning process to compile the messages into a summary generated by some AI. I would then divide the context size by ten, enabling one year of analysis.

Hi Sébastien Flory I confirm that the issue is fixed The queries are working again 🤝 For my culture, im curious to know what was the issue and the fix Thanks !

alright thanks

hello Sébastien Flory any updates please ?

Sébastien Flory maybe this is an important hint as well https://dustcommunity.slack.com/archives/C06SHT0F20G/p1743067551442709?thread_ts=1743006925.675239&cid=C06SHT0F20G when I first got this error, I was using a view but ever since, the error persisted even with using native tables from a different dataset, even using completely different credentials and refreshing the BQ connection

Of course, I already did a bit further up in this thread (I have added an emoji ⭐ so you can spot it quickly) That was one of the queries the agent was producing.

Hi Sébastien Flory thank you for your answer; actually, I have tested with lowercase tables as well but got the same result, that is unless using the uppercase view at the beginning somehow created a state of lock where that process of comparing tables got disrupted ? Is this check made in some kind of stateful approach ? and not everytime by checking the existing tables explicitly ? 🤔 (I can certainly understand the desire to economize on the read operations ^^)

Hi Abboud Hammour this just a kind reminder about the ticket, if not already created ^^ have a great day