Allow multiple success responses in ApolloCall.execute()

[BoD]

Rationale / decision record

• Calling execute() on subscriptions or other multiple success responses cases makes little sense, which is why we were failing fast with a clear message
• However the cache's CacheAndNetwork fetch policy can emit 0, 1, or 2 success responses, so execute() may not always crash - e.g. it doesn't crash during tests, but crashes in production (aka, "foot gun").
  • User facing this: Slack
• Recognizing this, in Cache v1.0.0-alpha.5, CacheAndNetwork has been deprecated, noting that it is relatively trivial to re-implement it in user code
• However since projects are already using it, this raised concerns
  • Clarify CacheAndNetwork replacement apollo-kotlin-normalized-cache#213 (2 users)
  • User disappointed by the deprecation: Slack
  • User currently using CacheAndNetwork: Slack
  • Discussions with Deezer
• Decision:
  • Don't crash in execute() but rather return the first success response.
  • Revert CacheAndNetwork deprecation

That would be technically a behavior change, but one that can only have 'good' consequences?

Pro/cons

• Pro: fewer crashes
• Con: execute() with multiple success responses still make little sense, but by not crashing we're not educating the user

[apollo-librarian]

✅ Docs preview ready

The preview is ready to be viewed. View the preview

File Changes

0 new, 1 changed, 0 removed

* (developer-tools)/kotlin/v5/advanced/network-connectivity.mdx

Build ID: 0b8b734c2f2892efb6ad9b4e
Build Logs: View logs

URL: https://www.apollographql.com/docs/deploy-preview/0b8b734c2f2892efb6ad9b4e

[martinbonnin]

Can we make a decision record here? Like why we deprecated it, issues where users complained, why we are undeprecating it and now why we are not throwing any more?

[BoD]

I've updated the description.

[martinbonnin]

Thanks for providing the context. In a way, CacheAndNetwork is "stale-while-revalidate" when used with execute().