Universal SQL: Filter interaction not triggering on parquet source

[matsonj]

Steps To Reproduce

When opening this page, the filter component does not allow the data set to be filtered.

This is hosted on Netlify, so it is possible that there is an issue between the browser and netlify that is causing the filter to fail.

The underlying code can be found here.

Environment

• Node version (node -v): 20.10.0
• npm version (npm -v): 10.2.3
• OS: Windows
• Browser: Chrome
• Database: n/a (USQL)

Expected Behavior

Filter should allow you to select a specific team and view their future games.

Other notes

Works totally fine in dev mode on local (in a codespace).

[archiewood]

@matsonj are you able to reproduce if you preview a local build? This will isolate build issues vs netlify issues

I like to do this with http-server:

1. npm run build
2. Install http-server: npm i -g http-server
3. Preview: npx http-server ./build

[matsonj]

@archiewood I can confirm that in a full local preview build, this issue does NOT replicate. Is Netlify compatibility a goal with Universal SQL? I am happy to move to evidence hosting if you can support custom domain names!

[matsonj]

On second thought, I am using a github action to deploy to netlify. I am going to make an alternative deployment model using the evidence docs and see if that version of the site shares the same issue. Its probably irrelevant.

[archiewood]

Unless there is a hard technical reason why it cannot, I think continuing to support Netlify would be good.

Custom URL feature request noted

[matsonj]

Oh I think I might have something. When I ran npm run build a second time and then served it up, I can now get the no magic bytes found error. Doing some more experimenting to see if I can pin down exactly why this is occuring. My theory is that the cache needs to be invalidated / reset on netlify for every build.

[joedelia]

@matsonj were you able to figure this out? we're also seeing this, only reloading the page with "disable cache" seems to fix it

[matsonj]

@joedelia I have not been able to fix, still open from what I have seen.

[csjh]

@joedelia could you give some details on the context in which this is happening? Are you on a Netlify deployment? Is it only happening around the time of fresh builds? Also, is it happening consistently or rarely?

[joedelia]

Ok from what I could work out it seems to be something to do with the Cache-Control header and the Range header.

We are actually deploying this a bit differently so it might be a very edge case. We essentially build the static files in a Docker container on a server in our AWS environment and then the files get shared to another container running node + express to serve them as static files. This is because we have custom rules over which admins should access the data.

I noticed the way we were caching them was incompatible with the Range header. I kinda assumed that the files were immutable and didn't need to be revalidated, because of the hash, but then it seems like the cache was returning a different range from the one requested.

Changing to must revalidate with etag seems to work!

[csjh]

Ahh yeah the hash might be a bit deceiving, it's a hash of the query text (i.e. SELECT * FROM table), not a hash of the results - likely the source of this issue. Thanks for the info!

[matsonj]

YES

[archiewood]

@matsonj we now also have an internal beta of custom URLs, if you are interested in trying it sometime

FYI @Winterhart

[mjbloch]

I believe I am running into this same issue - similar situation related to use of a dropdown filter and same error message. Deploying with Evidence Cloud. Sometimes resolves itself after an arbitrary amount of time. Opening in incognito or clearing cache appear to be workarounds.