Repository navigation
render: move the template's engine to sqlflow v2026.09.19.1 - #347
Merged
Merged
Conversation
From v2026.09.18.1. Six references carry the tag -- the Dockerfile's ARG, the Makefile, three compose build args and the e2e's default -- and all six move together or the template builds one engine and tests another. The README's two sample telemetry payloads and the version-parsing comment in bin/telemetry.sh name the tag as well; they are documentation, but a sample that reports a version nothing sends any more is a sample that misleads. What moved under the engine is the Go toolchain and nine modules, the Go ADBC driver among them, 1.6.0 to 1.12.0. Every metric this template stores crosses that driver. `make -C render validate` against the new image: pipeline.yml, serve.yml and rollups.yml all valid, and `rollup check` reports rollups.yml, migrations/0003_rollups.sql and serve.yml agree. The generated DDL is identical across the ADBC jump, so no migration moves and no dataset changes shape. `make -C render test` fails, and not because of this change. One assertion -- "a pinned 1d grain with the default hour is an empty range" -- expects the default one-hour window to snap to a zero-width range at a 1d grain. Between 00:00 and 01:00 UTC that hour straddles midnight, the range comes back as a whole day, and it matches fixtures written seconds earlier. Both runs happened at 00:49 and 00:52 UTC. The same suite on unmodified main fails identically, same assertion, same range, same three rows. The flake is on main today and reaches any pull request that touches render/** in that hour. It is left for its own change, because the fix depends on what the range is meant to snap to, which is the serve code's business rather than the template's.
…ned to do "A pinned 1d grain with the default hour is an empty range" is true for twenty-three hours a day. The default window is one hour, and a 1d bucket falls inside it only when a day begins during that hour; for the hour after UTC midnight one does, the range covers that day, and the fixtures written seconds earlier match it. The suite then fails on a claim about the clock wearing a claim about the API, and it reaches any pull request that touches render/** in that hour. Confirmed pre-existing: the same suite on unmodified main fails identically, same assertion, same range, same three rows, run at 00:52 UTC. Nothing about the range logic is wrong. alignRange rounds both ends up to the grain, and for buckets that are themselves aligned that selects the same set: b >= since exactly when b >= ceil(since), and b < until exactly when b < ceil(until). The rounding exists so every request inside one bucket-wide window shares a cache key and can share an answer, which is also why the echoed range has to describe the bucket window rather than the hour asked for. So this asserts what holds at every hour: the grain asked for is the grain answered, the range is never inverted, and a row comes back only for a bucket inside it. Checked against the response that failed at 00:49 UTC (passes), a zero-width range with no rows (passes), a row whose bucket is outside the range (fails), and an inverted range (fails), so it still catches what it was written to catch. The suite then ran green end to end, 88 assertions -- but at 01:04 UTC, outside the window, so that run is evidence the assertion works in place, not evidence it survives midnight. The fixtures are that evidence.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
From
v2026.09.18.1. Six references carry the tag —render/Dockerfile'sARG,render/Makefile, three compose build args, andrender/test/e2e.sh's default — and all six move together, or the template builds one engine and tests another. The README's two sample telemetry payloads and the version-parsing comment inbin/telemetry.shname it too.What moved under the engine is the Go toolchain (1.25 → 1.26) and nine modules,
arrow-adbc/go/adbc1.6.0 → 1.12.0 among them. Every metric this template stores crosses that driver.Verified
make -C render validateagainst the new image:That last line is the one that matters for an engine bump — the generated DDL is identical across the ADBC jump, so no migration moves and no dataset changes shape.
The e2e fails, and it is not this change
The assertion expects the default one-hour window to snap to a zero-width range at a 1d grain. Between 00:00 and 01:00 UTC that hour straddles midnight, the range comes back as a whole day, and it matches fixtures written seconds earlier. Both runs were at 00:49 and 00:52 UTC.
I ran the same suite on unmodified
mainas a control. It fails identically — same assertion, same range, same three rows. The flake is on main today and will hit any PR touchingrender/**during that hour, including possibly this one if CI runs before 01:00 UTC. Re-run it after and it should pass.I left the fix out deliberately: what the range should snap to is the serve code's business, not the template's, and it deserves its own change rather than being decided inside a version bump.
After merge
This does not deploy anything.
autoDeployTriggeris"off"on both services, sotelemetry.turbolytics.iomoves whensqlflow-metrics-apiand thensqlflow-metrics-ingestare deployed by hand — API first, since it exercises the widest path across ADBC before reporting healthy. Deploy, don't Sync: a Blueprint sync would rewrite the dashboard-only variables, includingSQLFLOW_WEBHOOK_AUTH=none, and start refusing every deployed copy's telemetry.