New token scope for monitoring¶

The ORG_DATASOURCES:READ scope helps you consume Service Data Sources at the organization level, for example organization.datasources_ops_log, in a safer way, without the need of using an admin-level token.

This is useful for organization level monitoring, such as the one provided by the tinybird-org-metrics-exporter project template to monitor organization metrics using Prometheus endpoints and Grafana.

You can create a token with the ORG_DATASOURCES:READ scope only through the API. To create a token with the new scope, call the Tokens API. For example:

POST https://api.tinybird.co/v0/tokens/?name=prometheus_org_access&description=optional&scope=PIPES:READ:organization_metrics&scope=ORG_DATASOURCES:READ

Query timeout status code changing from 408 to 504¶

Starting on January 27th, 2025, Tinybird will change the HTTP status code returned for query timeouts from 408 (Request Timeout) to 504 (Gateway Timeout).

If your application currently handles 408 errors, you will need to update your code to handle 504 errors instead. Also make sure any automatic retry mechanisms in your application are aligned with the new status code.

We are doing this for the following reasons:

• A 504 code indicates a server-side timeout rather than a client-side one, which better reflects what’s actually happening when a query takes too long.
• Firefox treats a 408 error as a client timeout and automatically retries requests. This caused repeated retries for queries that had legitimately timed out. Switching to 504 resolves this issue.

This change will go live on January 27th, 2025. We recommend preparing your applications and exception-handling logic well before that date to ensure a smooth transition. If you have any questions or concerns, reach out through our usual support channels.

Improvements and bug fixes¶

• We've streamlined the autocomplete behavior in the query editor when working with multiple Data Sources and Data Source prefixes. For example, source.column_name are now only added to column names when necessary to avoid ambiguity between Data Sources.
• When a Data Source is renamed, all your Pipes are updated to use the new name. We've improved the renaming behavior to prevent unintended changes to queries that use similar names for columns or aliases. Renaming a Data Source now only updates the Data Source references while preserving all other naming elements in your queries.
• Fixed a bug in Sink Pipes where parameters weren't being correctly propagated when used in both column conditions and file templates across multiple nodes. This affected scenarios where a parameter was used to conditionally add columns while also being used to determine the output file path.