Added wait=true to all Tinybird events API calls

[cmraible]

While testing the migration from JSON field to String field, I found that Tinybird was accepting events but dropping them on the floor for a split second during the deployment. It turns out that Tinybird's event API will return 202: Accepted to confirm receipt of the events, but that doesn't guarantee the events are actually written to the database. This means it's possible to get a 202: Accepted from Tinybird, but the events are potentially lost forever.

There is a wait query parameter that we can pass in our API requests, which will wait for confirmation that the events were actually written to the DB before returning. With this option set, the Tinybird API will return an API error if the events are dropped for whatever reason (i.e. during a deployment cutover). The worker process will receive the API error and nack all the messages in the batch, which prompts them to be retried.

[9larsons]

Good find. A couple callouts:

• Joe set up monitoring so we should watch and make sure this doesn't significantly impact our submissions as we can definitely expect a slower response time. Not terribly concerned here.

• We should be returning a 200 instead of 202 when using wait=true. createMockUpstream and related tests should be updated. This one feels a little important in case we check for explicit response codes. The response otherwise seems the same.

[cmraible]

@9larsons Good points!

Joe set up monitoring so we should watch and make sure this doesn't significantly impact our submissions as we can definitely expect a slower response time. Not terribly concerned here.

Yep 100%, agree we'll need to keep an eye on this.

We should be returning a 200 instead of 202 when using wait=true. createMockUpstream and related tests should be updated. This one feels a little important in case we check for explicit response codes. The response otherwise seems the same.

Thinking this through, this is a good instinct but I think the current behavior is still correct:

• In Proxy mode, we don't use this client — we just proxy the request to Tinybird directly using reply-from. In this case, we just pass the response from Tinybird straight back to the browser, and that would still be 202.

• In Batch mode, we're still returning immediately after publishing to Pub/Sub — so I think 202: Accepted still makes sense for the response from the analytics service. It's only the worker that uses the Tinybird client (for now — probably a good idea to harmonize that).