> It's an opt-in feature, and it's not default-on.
The documentation sounds like it's a global switch though? This is really a per-function property…
> But I think it's a bounded enough problem for a language processor (ala LLM) that can yield good enough results for vast majority of the use cases.
If as a developer I want this feature I'm not sure why I wouldn't just stick a "retry" annotation somewhere in the function declaration (schema file, export, whatever.) I can see the utility of having the RPC layer handle this for me, particularly for pure compute functions. That's "good enough" error handling: the developer correctly identifying which functions are retryable, erring on the side of caution, and getting automatic retries for those (and just those.) Other RPC errors bubble up.
What benefit AI gives here — especially in this form, hidden in the RPC layer — I don't see at all. If I want AI to help me identify which functions are retryable, I'd rather have it do that in my editor by visibly sticking the "retry" attribute on the function. That way I can fix it if it mis-guesses.
Also: what do you do if with your RPC implementation the guess is wrong and a function is retried when it really shouldn't be? What's the fix?
> The documentation sounds like it's a global switch though? This is really a per-function property…
It is a global switch per cluster, yes. Agree that it should be a per-function property, and we're working towards that. It's currently in beta.
> What benefit AI gives here — especially in this form, hidden in the RPC layer — I don't see at all. If I want AI to help me identify which functions are retryable, I'd rather have it do that in my editor by visibly sticking the "retry" attribute on the function. That way I can fix it if it mis-guesses.
I think you're mistaking "identifying functions" with "identifying failures". The AI does not identify which functions are retryable. That's your job as a developer. The AI helps with figuring out which *failures* are retryable.
You can't potentially account for all retryable cases in your code. Some exceptions happen in underlying libraries, database drivers and OS level that you might not have see before.
The documentation sounds like it's a global switch though? This is really a per-function property…
> But I think it's a bounded enough problem for a language processor (ala LLM) that can yield good enough results for vast majority of the use cases.
If as a developer I want this feature I'm not sure why I wouldn't just stick a "retry" annotation somewhere in the function declaration (schema file, export, whatever.) I can see the utility of having the RPC layer handle this for me, particularly for pure compute functions. That's "good enough" error handling: the developer correctly identifying which functions are retryable, erring on the side of caution, and getting automatic retries for those (and just those.) Other RPC errors bubble up.
What benefit AI gives here — especially in this form, hidden in the RPC layer — I don't see at all. If I want AI to help me identify which functions are retryable, I'd rather have it do that in my editor by visibly sticking the "retry" attribute on the function. That way I can fix it if it mis-guesses.
Also: what do you do if with your RPC implementation the guess is wrong and a function is retried when it really shouldn't be? What's the fix?