Repro is with Zui commit 21abbf6. This issue was reported by a community zync user. They connect to remote lakes in their environment that are running Zed lake service v1.14.0.

We prepare by starting a Zed lake v1.14.0 service and loading it with some data.

$ zed serve -lake lake -l localhost:8888

$ zed -lake http://localhost:8888 create -use foo
$ zed -lake http://localhost:8888 load sample.zng

In the attached video, we first make these preparations, then from within Zui 21abbf6 we click Add Lake and make the connection to the "remote" service we just started on localhost:8888. For any query we issue, instead of query results we are shown Error: 404 page not found.

We discussed this one as a group. The root cause of the problem begins with the changes in #3076 when Zui began hitting the Zed service /query/describe endpoint introduced in brimdata/super#5126. Interestingly, the user-facing symptom did not surface right at the point when #3076 merged. Studying traffic in Wireshark we can see that the HTTP 404 is being returned by the Zed service when the app tries to hit /query/describe, but the app was not surfacing it and instead the user saw their query result as always. It's only with the changes to the error handling in #3085 that the Error: 404 page not found started being surfaced.

In terms of a fix, we agreed the high-level goal is that we want Zui at tip of main to still be able to work with lake service versions that lack the /query/describe endpoint, even if some functionality is not available due to the version mismatch. We reached consensus that a reasonable fix would be for the app to recognize if /query/describe is not available and, if so, just execute the query and present any errors that come back. This means that the user will be missing out on the improved error handling we're enabling via /query/describe so we could perhaps surface some informational message to that effort (i.e., to nudge them toward upgrading their lake service versions) but this was not seen as "must have" functionality. It was also noted that pagination and drill-down would not work in the absence of /query/describe, so we should make sure this functionality gets disabled in a friendly way.