A question about TimeGPT and exogenous variables from Antoine SCHWARTZ -CROIX- <antoine.schwartz@decathlon.com>. Code and data in thread.

I'm a long-time user of your open source packages (which I can easily get to work with exogenous variables). But with TimeGPT I get strange bugs.

In pandas, everything works fine with X_df=None, but I get a WriteTimeout when I use it on my entire dataset (30k+ time series), even when tweaking num_partitions.

I've also tried using Spark, without success but with different errors.

I don't think I made any mistakes in preparing the datasets because everything works correctly with neuralforecast or mlforecast.

The simplest thing would be for me to share my (anonymised) data with you so that you can test it yourself?

Thanks in advance!

the biggest advantage of cloudfare is perfromance— it allows requests up to 200mb and is faster. All these advantages are mitigated if the way we access cloudfare is behind the slower and more limited Firebase

yes, docs should be updated to show the new url

could you look into a full deprecation plan for firebase Edu?

@Tracy Teal can you please tell the user to instantiate the client as:

client = NixtlaClient(base_url='<https://api.nixtla.io>')

? That should solve the issue

@kevin It just needs a replace everywhere, no need to change anything to continue supporting both urls

If we want to support both urls, we should ensure

<https://dashboard.nixtla.io/api/>

calls Cloudfare directly. Otherwise users will keep bumping into this issue. They'll think calling

<https://dashboard.nixtla.io/api/>

and

<https://api.nixtla.io>

is the same, but one is slower and has a much lower request limit than the other.

I think we need to support the previous url to prevent breaking users pipelines. Current version in firebase is still faster than the one from 3 weeks ago, so no need to decide anything extreme. To make the url fully go to cloudflare you would need to host the dashboard in a server that has that url configured to cloudflare but seems like an overkill IMO. We should just update the docs and let people migrate themselves over time. Maybe also a deprecation message can be added in the firebase response, same as we have for deprecating /timegpt endpoint

I trust your judgement, sounds good. Make sure the limit for each url is clear too, cause this isn't the first user to hit the 32mb limit, and it's an issue we can't handle on firebase— it just errors out before we can let them know

I mean, when you update the docs to have the new url and have the deprecation message on the previous one both in docs and API that seems pretty clear to me.

I'm very busy, could you do it please?

sure

thanks for opening the pr to update the base url in the sdk, @Edu, i left a comment. we also need to change the url in our reference docs. we've opened a pr to fix that as well.

ty @azul (she/her) (nixtla)! just sent both