You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
Repro.mp4
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.
The text was updated successfully, but these errors were encountered:
As shown in the attached video, now I can connect to my "remote" Zed v1.14.0 lake service and see query responses without error.
Verify.mp4
As described in the notes above, some functionality is disabled when the newer Zui version is accessing the older Zed lake service. The video in #3104 (comment) gives a walk through of what's disabled. I've verified that the differences shown there are much the same at Zui commit 10d8974, but have just chosen not to re-cut a redundant video.
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.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.Repro.mp4
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.The text was updated successfully, but these errors were encountered: