Viewport ID Discrepancies From Service Calls

[stricklandrbls]

Currently, the data editor is utilizing message command parsing between the UI and extension for obtaining viewport data information instead of utilizing the viewport subscription events. This is done mostly with the getViewportData(...) function signature defined in the module.

When attempting to forward viewport data from subscription events, I found that there is no value within ViewportEvent types for the remaining byte count that is needed by the UI and extension.

When trying to implement some functionality for obtaining this on subscript events, I found that the ViewportEvent.getViewportId() return a viewport id in the format of 49fb04aa-4b06-4300-b9bc-ae9f69d332a3. Attempting to invoke API calls, such as getViewportData with this viewport id structure causes the server to fail due to a malformed viewport id in the request.

The only correct viewport id structure seems to be the structure of <session-id>:<viewport-id>, such as in the ViewportDataResponse.getViewportId()

[scholarsmate]

There are at least 2 places where the viewport IDs are not of the "compound" type of session_id:viewport_id, but are instead just coming out as viewport_id, which is the discrepancy being reported.

The two locations where this is occurring is in the viewport unsubscribe function and in the viewport event object that gets returned to the callback that happens when a viewport has changes.

I've been able to reproduce the problem by updating the typescript client test cases to check the IDs. These test cases are currently (now) failing with the additional checks. Once the viewport IDs get fixed in the Scala server, those test cases ought to then pass.