Exhaustive retrieval builder page: filtering search / timeframe

[philipperolet]

Context: issue #1864, and design doc with visual

Since testing locally is not trivial (requires either talking to local datasources, or adding remote datasources), I can merge and test--and revert quick if issue

[spolu]

What happens to existing agents?

[spolu]

Will they all land on the right settings in the builder with their existing configurations?

[spolu]

Tested locally creating an Auto / Custom1Month / AllTime and then merging to your branch.

Auto and Custom1Month are properly mapped to Search and TimeFrame in the UI, but this is a bit of a lie since really Custom1Month is not query=null right?

AllTime gets mapped to Search which makes sense but is a bit of a lie since it'll still force all time right?

• I presume we can somewhat safely migrate AllTime assistants to the new Search settings (query auto, timeFrame auto)
• The problem are the old CustomXPeriod agents which will be trickier to migrate? We should probably look in DB for how many we have and maybe fix manually by moving to the new SEARCH settings but adding an instructions?

[philipperolet]

Cf the changes to front/pages/w/[wId]/builder/assistants/[aId]/index.tsx
=> those who were on "AUTO" or "ALL TIME" will be on search
=> those who were on "CUSTOM" swtich to "TIMEFRAME"
IMHO the most sensible switch

[spolu]

Yes but this is a read-only switch until the configuration is revisited and saved right?

[spolu]

So these are the custom timeframe assistants:
https://metabase.dust.tt/question#eyJkYXRhc2V0X3F1ZXJ5Ijp7InR5cGUiOiJxdWVyeSIsInF1ZXJ5Ijp7InNvdXJjZS10YWJsZSI6NjQsImZpbHRlciI6WyI9IixbImZpZWxkIiw1NjksbnVsbF0sImN1c3RvbSJdfSwiZGF0YWJhc2UiOjR9LCJkaXNwbGF5IjoidGFibGUiLCJ2aXN1YWxpemF0aW9uX3NldHRpbmdzIjp7fX0=

And here are the none timeframe assistatns:
https://metabase.dust.tt/question#eyJkYXRhc2V0X3F1ZXJ5Ijp7InR5cGUiOiJxdWVyeSIsInF1ZXJ5Ijp7InNvdXJjZS10YWJsZSI6NjQsImZpbHRlciI6WyI9IixbImZpZWxkIiw1NjksbnVsbF0sIm5vbmUiXX0sImRhdGFiYXNlIjo0fSwiZGlzcGxheSI6InRhYmxlIiwidmlzdWFsaXphdGlvbl9zZXR0aW5ncyI6e30sIm9yaWdpbmFsX2NhcmRfaWQiOm51bGx9

For the none I would feel OK simply migrating them back to auto.

For the custom ones we need a bit more thinking?

[philipperolet]

Yes; for the custom ones that are not our own, among which a share actually wants exhaustive retrieval, l would email with instructions to adapt, and contact to get help to do so (= eng runner = me)
=> your custom assistant has been updated, here's what it will do now etc

For the migration

• the fast option, that I favor, is to migrate all to exhaustive retrieval: probably what they actually want, if they don't the email explains and the runner can assist
• the more tedious option but still possible given the small number of affected assistant is to look at each and migrate according to what we believe is best, which would limit frustration / emails / calls

I'll have a look at a few of them in detail to get a sense

[spolu]

I disagree that the RelativeTimeFrame='none' should be migrated to timeframe filtering. It should be moved back to auto right?

[spolu]

As per IRL:

• We want to add a migration for relativeTimeFrame='none'
• This is obviously dependent on checking that query=none works
• We will also wait for a follow-up PR to be ready that will indicate when we were unable to fit all results in context

[philipperolet]

For the "custom", as discussed IRL, there are 3 non-dust non-archived assistants that are affected, I will deal with them manually

[philipperolet]

As discussed IRL with @gabhubert , migration & merge to be done monday morning