feat: Improve user experience when a query doesn't produce a record. #280
Assignees
Labels
enhancement
New feature or request
p1
Issues that are very high priority, but not "blocking"
user-study
Issues discovered during user studies
Comments
kerinin
added
enhancement
|
This seems like a duplicate of #273 |
|
If we want to go that route I think you're right, but there's still the possibility of just changing the error message. We could also stage these - change message now while the #273 is pending. |
|
Lets just change the error message for now. |
kevinjnguyen
added a commit
that referenced
this issue
May 24, 2023
kevinjnguyen
added a commit
that referenced
this issue
May 24, 2023
# Fenl Diagnostic HTML Rendering Updates the rendering of the Fenl Diagnostic to render HTML A tags for known and documented error. Also lays out the ground work for easy error documentation. The new implementation will scan through a Fenl Diagnostic for an error code using the regex `error\[(,?.*)\]`, then check to see if that code is documented as part of the `error_codes.py: FENL_DIAGNOSTIC_ERRORS`. If there is a documented error, the code converts the error code to an HTML <a> link. **Example of a pre-defined error:** (Note the hyperlink E0013) <img width="542" alt="Screenshot 2023-05-23 at 9 34 48 PM" src="https://github.com/kaskada-ai/kaskada/assets/15032894/052516fb-fa6f-4efd-b81c-857fa11a40de"> **Example of the default undocumented case:** <img width="727" alt="Screenshot 2023-05-23 at 9 35 20 PM" src="https://github.com/kaskada-ai/kaskada/assets/15032894/ec3996da-8919-467a-b4d7-b2a76440a31d">
kevinjnguyen
added a commit
that referenced
this issue
May 25, 2023
therapon
pushed a commit
that referenced
this issue
May 30, 2023
# Fenl Diagnostic HTML Rendering with Protos A second pass at implementing rendering of Fenl Diagnostics from the Engine upward. The UX is the same but now the source of truth is the Engine. ## Changes * Removes the custom python client approach * Updates fenl diagnostic to have a `web_link` as another field * Updates python client rendering to use the `web_link` field
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Summary
Currently, when a user runs a simple query like
count(Foo), an error is returned to the effect of "output type must be a record". This is the result of a query returning a non-record type, which isn't currently supported. This error is confusing to new users who don't know how to construct records, and aren't accustomed to this type of restriction in other systems.Improve the error message to suggest a remedy (ie, link to a docs section explaining records, or explain more clearly the problem and how to solve it).
(As noted below, changes to support arbitrary types are pare of #273)
The text was updated successfully, but these errors were encountered: