Why does the generate command cache the OpenAPI description?

[pschaeflein]

When I run generate, it creates a lock file with a hash of the description.

It seems that it also caches the description.

Subsequent runs of generate don't update anything unless the --cc option is included.

Why cache? If I'm running generate, it is most likely because I've changed the OpenAPI description of the API and I want the client updated.

[baywet]

Hi @pschaeflein,
Thanks for reaching out.

Kiota is only caching files loaded over the network (https scheme), local files are being read directly.
The reasoning behind the caching of descriptions is they can be lengthy to download, and they don't change often in most cases. We expect that most people will run multiple show/generate commands over one "session" to tweak their include patterns and whatnot. And we don't want them to pay the cost of downloading the files multiple times.

The hash is orthogonal, once we have the file, it skips re-generating if the description hasn't changed. But we need to have the description first.

Of course the assumption breaks down if you're editing the API definition at the same time, which I think is what you're doing.

Can you tell me more about your workflow? Do you have the service also running locally? are you generating from a description that's "hosted" on localhost? Maybe we could/should skip caching for anything that comes from localhost.

[pschaeflein]

We expect that most people will run multiple show/generate commands over one "session" to tweak their include patterns and whatnot. And we don't want them to pay the cost of downloading the files multiple times.

Yes. Reasonable.

Of course the assumption breaks down if you're editing the API definition at the same time, which I think is what you're doing.

Yes, exactly. Reading from localhost: kiota generate -d http://localhost:3979/...

Maybe we could/should skip caching for anything that comes from localhost.

I like that idea. (Of course, now that I know what's happening, I just include the flag. 😏)

When using the VSCode extension, perhaps a tickbox to force the download (the equivalent to --cc)?

Thanks!

[baywet]

Thanks for the additional information.

I think the localhost improvement is contained enough that we can schedule it.

The vscode extension relies on the same exact engine under the covers, so it's going to benefit from that improvement too. As for the settings, we haven't designed setting for the extension but this (and --co, and others), could be part of those settings. The nice thing about vscode settings is they can be global (for the user) or local (for the workspace), enabling consistency across developers on a single repository.

We'll let demand drive those investments for now.

[baywet]

authored #3317 to implement the localhost change

[pschaeflein]

Fix (working as I want) in the VSCode extension v1.7.23092101.

Thanks!

[baywet]

Thanks for confirming!