trigger based query does not update results properly

[kortemik]

notebook 2JEF7JF7C on tg6 shows that while running a continuous query the output is not updated even though firefox network tab shows that there is new data coming in via the websocket.

please investigate why.

[kortemik]

only the first results are visible, the updated are visible only with the page refresh

[BVVLD]

Current status of the issue:

Trace log:

1. UI processes the paragraph as it should and sends a run request to server.
2. Server responds with two results for the paragraph. First result is a text field, second is a table with 1 column.
3. Server starts to update both result fields. The text field is updated via "Append_Paragraph_Output" and receives either "" or "\n" in updates, which makes the empty text field grow uncontrollably. The table constantly receives updates with identical information, which makes it stay the same.
4. No signs of any other data was found.

Conclusion: Server misbehaves, waiting for confirmation. Probably not a AJS_01 issue.

[kortemik]

@BVVLD @ronja-ui please update status

[kortemik]

@StrongestNumber9 reproduced this on tg7

[StrongestNumber9]

@StrongestNumber9 reproduced this on tg7

tg7 notebook/2K1PAMQ6Q or test-combined

[BVVLD]

tested on AJS_01 version 8.0.0: server indeed sends data updates, which UI ignores. However, once user switches to any graph and back to the table, the table starts to update. Here is the reason, why: initially, to display the results, server sends the updated paragraph object. Data for the results is in the paragraph.results array, and the config for it is stored in paragraph.config.results array. The indexes of the arrays are (or at least should be) synchronized. Let's assume, that the data is paragraph.results[x].msg and config is paragraph.config.results[x]. Since all current results are now graphs, all config is stored in config.graph. Here it should be a "mode" parameter, that tells which representation to use, "setting" array, which stored specific settings for each mode, "commonSetting" object, and also here is stored setting fields, like "keys", "groups" and "values", which you can see if you open a setting panel.

The problem is: server does not initially send the config object. Therefore paragraph comes without it and on every update it tries to apply update with the config, but fails, since there is none. So updates are discarded. Once user switches between graphs - it creates the configs and stores it in the notebook. After that, it starts to provide these configs every time the paragraph object is provided and everything starts to work as expected.

Current attempt to solve the problem: trying to make UI to render and process updates with empty config. If this will not work -> to add a defaulting mechanism, that will use at least some minimal configs to run. What problem that might create? Sometimes server sends empty result updates or empty data for results, which might mess up result object. Previously, some of these empty updates were cut out with empty config checks.

[kortemik]

ui should be responsible for providing the default rendering-config if it's not present, if it is use it. if there later comes update without one but ui has still previous config stored, use it.

[BVVLD]

The attempt to allow results render without config was a success. The "default rendering-config" will be implemented, since it is requested. It would be helpful to see at least some documentation on what should be there by default.

Otherwise, troubleshooting the issue also uncovered few other UX problems, mostly with DataTable controls, including flashing "default columns" button and bugs related to its functionality in raw-data tables. These issues are currently being investigated.